The term “technical debt” is a very useful metaphor. It helps to illustrate certain problematic peculiarities in software development.
Regardless of the apparent clarity of the term, I always have the feeling that people who have never been directly involved in software development cannot fully understand the real magnitude of the problem of technical debt. For those responsible for software projects, however, this would be very desirable.
In the following I will try to present this important topic in a simple and comprehensible way. I hope it helps to understand how too much technical debt can destroy the future of software.
Technical Debt are the intentional and unintentional violations of good architectural and coding practices. This debt will create increasing effort and cost to maintain, extend or innovate the software.
Put less technically, but just as applicable:
All the mess you leave behind when you think you are done.
The variety of solutions in the development of software exceeds anything known from the everyday world of things. And so, as a non-developer, one may underestimate the almost infinite spectrum of conceivable “intentional and unintentional violations” to which software development can tempt you. Due to time and budget pressure or incompetence, software is always full of imperfections. And although it does what it is supposed to do, these imperfections add up in the lifecycle and without countermeasures it becomes a burden for further development, which at some point gets insurmountable, either technically or economically.
A further definition would not help and so I would like to try with a story. I cannot say whether it actually happened that way. But it is so plausible and comprehensible for IT professionals in the software industry that it seems very realistic.
The following text is a free translation of this original Russian source, which reflects a comment-based exchange between various stakeholders (from development, quality assurance and project management) in a software project.
Let’s go!
Imagine you are a project manager building a historic fighter plane in a video game. After the first test flights, however, your customers notice an inaccuracy compared to the original: two white stripes are missing on the tail.
You transfer the matter to your QA manager, who in turn passes it on to a QA engineer. The latter delegates the task to the art director, so that it finally ends up with a texture designer.
The texture designer transfers the final creation of the stripes to a 2D designer. However, he replies that the team is completely overloaded and that the stripes cannot be created sooner than in two months. The texture designer then turns to the less overworked 3D design team. He reports that the exact required textures cannot be created in such a timely manner and asks for the stripes to be modeled based on already available best-fit textures.
[With this violation of architectural best practices – i.e., a misappropriation – the new technical debt begins here.]
Nine days later, the 3D designer notifies the lead developer that the white stripes are ready. The final step, he says, is merely to attach the stripes to the aircraft. The lead developer assigns a junior developer to do it. A month later, he announces completion.
After only two more days, the QA engineer reports a defect in the on-board machine guns: no one can be shot down anymore.
It takes a month and a half before the senior developer can nail down the problem: The stripes cover the MGs and in turn are made of a material that has bullet collision detection in it. The machine gun bullets can’t penetrate the stripes.The lead developer does not understand how the stripes could cover the machine guns when they are attached to the rear of the fuselage. The senior developer explains that the real MGs are actually in the rear part and the MGs in the wings are just fakes, only for appearance. It would be due to the history of the project, he doesn’t remember the exact reasons. In any case, the entire ballistics depended on this design. A revision would take too much time.
[This is where new technical debt meets old. One can imagine that a complete documentation would have made this new problem recognizable earlier and might have steered the development in the right direction].
After three weeks, the lead developer approaches the 3D designer with a request to remove the collision-causing components from the white stripes. He replies that this is not possible because the collision features are inherent properties of the textures and no other textures are currently available. The whitest texture he could find, he said, was from a spot on another aircraft, which happened to have 4cm of armor.
[Bingo, you can imagine that one should have turned back from here, but they didn’t.]
The lead developer is stunned by the hardwiring of the collision in the textures and asks the senior developer if it is not possible to map this through a separate setting. The latter doesn’t know how this should work, since material fatigue, for a realistic implementation of bullet penetration, is also coded in the alpha channels of the textures.
The back and forth lasts two more months until the player community manager gets in touch and upgrades the priority of the issue to HIGH: the players would have noticed once again that the stripes are missing and would lose interest in such an amateurish game. The project is on the verge of failure.
The lead developer reacts quickly and asks for the stripes to be moved so that they no longer cover the MGs. However, the historical consultant does not agree with this at all: all details are measured to the millimeter based on historical photos, and he would not support a change under any circumstances.
The lead developer resigns and asks the senior for some solution to finally make it work. The situation is hopeless, he says. The senior decides to increase the MGs’ firepower from 2 to 231. This would use up 229 units to shoot through the stripes, leaving the remaining 2 for the bullets’ usual trajectory.
[This is a typical situational (mis)decision that will soon blow up in the software developers’ faces].
The senior developer closes the issue after two months and announces that everything should be fine now. However, the QA lead vehemently counters this after another month. He angrily reports that the firing power of another aircraft model is now increased to such an extent that it effortlessly destroys everything and everyone, which is absolutely unacceptable.
The problem is immediately clear to the game designer. The other model uses the same MGs, but scaled tenfold. The shape of the MGs of both models is similar and so it was decided at the time to save on additional modeling. The firepower also scales automatically, but with a factor of 1000, proportional to the diameter of the barrel, which ultimately results in a gigantic firing force.
The senior then indicates that the entire architecture of the game engine would have to be changed to allow dynamic collision adjustment of textures, which would take half a year of work. The lead developer knows that such decisions can only be made at the highest level and hands it over to the project manager.
The project manager then says that he has decided that it is easier to remove the critic who had complained about the inaccuracies regarding the white stripes from the community. The matter with the stripes was settled, and everyone should go about their normal tasks. He would now consider how to justify the exclusion.
[In this case, the only correct decision. So much technical debt was built up here in a short time due to time and budget pressure that further development of the game could hardly have been afforded].
Technical debt destroys development work that has been done. And often far more than the corresponding improvement measures or debt-free solutions would have required. In this case, the team is back to square one after 12 months without a solution to the actual problem. The two sensible alternatives – to wait 2 months or to carry out an extensive improvement within 6 months – were rejected.
However, wrong decisions usually reveal themselves only in retrospect and are often difficult to predict despite the expertise of the specialists.
Finally, a summary of the important characteristics of the technical debt built up in this example:
Most importantly, technical debt cannot be avoided a priori. But it can be kept under control by following best practices in development processes and regular assessments and adjustments of the architecture.
[1] dzuikaku.txt: http://yadi.sk/d/wcByE6pH6VTjP (original source)
You can find more on the subject of technical debt in our blog, in particular how it can be measured and quantified in the code beyond gut instinct: Corona-Warn-App – On the Way To Critical Technical Debt?