Majority of programmers with some sense of pride would tell you they write the best possible code with uncompromising quality. Of course this isn’t true, and most of the time not even realistic. Unless you’re building software for a NASA space probe, aiming for ~90% perfect is probably the most cost effective.
My colleagues might consider me demanding (read: asshole) because I often criticize their code, but I’m not a compulsive perfectionist and I do settle for less than perfect solutions when it’s justified.
What do I mean when talking about quality? Most of the time it’s about the maintainability of the code:
- How easy it is to understand?
- How confidently can you modify it without breaking anything?
- How much work is spotting and fixing errors?
You can achieve these by following the basic software development principles, such as the SOLID principle which I consider fairly important. Having a comprehensive set of automated tests is another basic requirement.
The best part about having automated tests, at least in the ideal case, is that your code doesn’t need to be perfectly written as it can always be refactored easily, whereas code without tests cannot be refactored with as much confidence.
There will be times when you realize that you can do something quickly or you can do it properly, and the temptation to get the task over with quickly can be great. Sometimes the cost of doing it properly is too high, or the component being written is so unimportant that it doesn’t matter, Most of the time though, I would advise my colleagues to take the time doing it properly, even if it takes more time. If there is no time to do it properly then the time estimation has failed.
If you constantly take the shortcut, you risk leaving behind a significant amount of technical debt which needs to be paid later, possibly by someone else. Throwing competent programmers into maintenance projects where majority of the codebase was written hastily is a good way of making those people consider alternate career options. It’s also important to keep in mind that it’s not just about that the code works, it’s also about how easy it is to understand, because reading poorly written code often incurs unnecessary mental overhead.