Once upon a time there was a triangle. It was the traditional project management “iron triangle” of cost, time and quality. (Sometimes time is replaced by scope.) The principle we learned was “you can fix any two, but it will affect the other”. The fact that it wasn’t entirely flexible gave rise to the “iron” element.

But in my own experience life was never that simple. Oddly, if I tried to sacrifice code quality on a project then we would still spend much unplanned time (i.e. long nights) fixing bugs.

In recent years the software movements around agile and lean have taken code quality out of the triangle. Lean, in particular, seeks to eliminate waste which comes predominantly through “re-work” — in other words, going back over things you thought had been finished.

I have found that outlook to be much more practical and productive than reducing code quality, and it’s something I insist on for all my teams. Simply reducing code quality hides problems for later, and that later time is never a time of your choosing. Thus, you usually find yourself fixing problems when you could be making positive progress (or sleeping). Maintaining high quality here ensures consistent progress.

I recently spoke to a friend who was investigating a troubled software project. It was overrunning and not doing what the client intended it to do. His analysis was that the quality of the code was so poor it had reached a point of paralysis, which explained much of the lack of progress. Changes — including bug fixes — were immensely difficult to make. Indeed, he thought it would be easier to start again than try to recover what was there.

Maintaining code quality absolutely does not mean systems have to be gold-plated. Nor does it mean that you cannot flex on other kinds of quality, as I’ve written about before. But maintaining code quality means you know for sure your system or feature does the thing you intended it to do. It can also mean you are aware of what it doesn’t or cannot do, and you made those choices consciously. In practical terms this means you have tests (and test results) to prove that it does what you intend and you are consciously managing technical debt.

Those two things mean you can be sure the work you’ve done is really done, and you are less likely to be bitten by unexpected problems later.