The Importance of Defining
By Alexander Von Zitzewitz, CEO, hello2morrow
Alexander Von Zitzewitz, CEO, hello2morrow
The nicest thing you can say to a project manager or your boss is something like “I am done with my task/project”. Everybody loves people who are getting things done. If you do that consistently you will get rewarded and used as an example for those other slackers who are having a bit more trouble with getting things done. On the other hand people who write beautiful, elegant and maintainable code hardly ever get any recognition for that. Nobody really seems to care about the ‘internals’ as long as the software somehow does what it is supposed to do. In a cultural environment like this technical quality, code maintainability and sustainability in general are easily thrown under the bus.
"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."
The Problem
My point is not to neglect the importance of getting things done, but to have a closer look of the meaning of ‘done’. For most organizations this is defined somehow like this:
- The testing department confirms that the use cases work as expected
- Performance and user interface seem acceptable
Please notice what is missing here? There is no requirement to prove conformance to all defined coding and quality standards. While many companies have formally defined those standards there are hardly ever enforced in a serious way. What's the point, after all? The software is running. Why would you invest any more effort into improving invisible things like technical quality or conformance to coding standards? Well, in some cases this would in deed not make any sense. If you know that the software will never ever be touched or changed again any extra effort for "beauty" would be wasted.
But on the other hand - how realistic is that assumption? Every non trivial system has bugs, so you would at least have to touch the code to fix bugs. The probability of bugs increases sharply with sloppy technical quality. Most systems will also grow over time
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.
