The Importance of Defining

The probability of bugs increases sharply with sloppy technical quality. Most systems will also grow over time when new features and requirements are added. A lack of technical quality or technical debt will lead to significantly higher maintenance cost and making it much more difficult to add new features or modularize the system.

More importantly, if developers know that conformance to coding and quality rules is not as critical as getting the job done they have no incentive to follow the rules. Just the opposite, they will get penalized for doing so because doing things right might take a little bit longer. If they watch other people getting rewarded for being ‘done’ even with lackluster internal quality metrics they will quickly learn their lesson and accept the accumulation of technical debt as a tolerable side effect of getting to the goal faster. Ultimately this leads to a culture where ever increasing technical debt is just baked into the process.

The people on the top are often afraid that imposing stricter rules might make things even more costly and therefore put even more time pressure on the projects because that will presumably lower the immediate cost impact. Of course technical debt comes with a high interest rate, so all short term savings will be eaten by much higher cost of change down the road. In fact we can assume that the uncontrolled growth of technical debt will easily double or even triple the lifetime cost of a software system. 

How to Solve It 

So, what can we do about all that? I'd say the solution is quite simple. We need to be more specific about the meaning of ‘done’ by adding a third bullet point to its definition: 

• The testing department confirms that the use cases work as expected 
• Performance and user interface seem acceptable 
• The code conforms to all rules regarding technical quality and architecture 

The usefulness of such an extra rule should be obvious. In all other engineering disciplines you check the quality of all parts before you integrate them into a system. We would not have safe airplanes, cars or trains without some serious efforts to control quality on all levels of operation. Only in software development it is quite easy to get away with bad internal quality because it is mostly invisible.

If you add the third bullet point nobody can claim to be "done" without proving conformance to the rules. Now people have a strong incentive to follow quality and architecture rules throughout the development process. And rewarding people who are "done" makes much more sense because cheating by taking on technical debt in favor of speed is not an option anymore. Interestingly enough you will find that following the rules all the time will soon become second nature to all developers and lead to increased velocity over time. Avoiding the accumulation of technical debt will also avoid the interest payments down the road, which will increase team efficiency and agility and keep the cost of change on a reasonable level.

In a future article about technical debt, I lay out some ideas for a small and simple rule set that can be used out of the box. In addition I also look at the accumulation of technical debt as a strategic tool to achieve important goals outside of the domain of the development process.