Jared wrote a great post about pragmatic use of less than perfect code.
“There’s such a thing as judicious use of shitty code. “
People that know me and my perfectionist bent might be surprised to learn that I’m a strong proponent of shitty code. Not all my code is shitty, of course. But some is. And I think that’s a good thing.
Moreover, I think you can be smart about how and where you use shitty code: the time invested in code quality should be relative to how much maintenance and/or reuse the code will see.
When you’re building a one-off controller that’s not likely to be reused, in a high-risk market, on a small app: code quality is a YAGNI. When you’re building a reusable view that will be useful in several areas (high reuse) – or is a key component of a large app (needs maintenance) – or on a very large project (need refactoring) – then by all means, take your time, do it right. The investment will pay off.
The important thing is to realize that code quality has a short-term cost and a long-term benefit. Invest more in the short term cost when the long-term benefit is likely to pay off.
Code quality is just one knob you have to adjust in your project – it doesn’t always have to be set to 11.