Technical debt; is it only technical?

The metaphor technical debt was introduced at the OOPSLA conference in 1992 by Ward Cunningham. The phrase was:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…
The danger occurs when debt is not repaid, for debt-recovery companies like moorcroft are hard to get rid of. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
The following picture shows how this “stand-still” described by Ward Cunningham is achieved.

How to Break the Vicious Cycle of Technical Debt
In most discussions/blogs on the internet the following causes are mentioned and most are code related:

• the business forces the development team to take shortcuts, aiming to get the requested functionality life as soon as possible.
• the development team thought they didn’t need to design.
• the development team was incompetent/didn’t bother to write maintainable/changeable code.
• the development team  recognizes later for example by incorporating a change, that they made a suboptimal decision in the past (difficult to avoid).

Martin Fowler summarized this very well in his blog “TechnicalDebtQuadrant“. He distinguishes between reckless vs. rational behavior and  deliberate vs. carelessly/naively choices. But this is still mainly code related.

But if you look at the forms of technical debt in real life situations, you’ll see that these are not only code related. Technical debt may manifest itself in the following form to us:

• Code form (as mentioned already), e.g. duplication, high McCabe index, high unit-length per method, high number of parameters in methods, wrong comments, unclear naming of objects, methods, variables and properties, etc.
• Architectural form, e.g. violating separation of concern, the choice of not using a third party framework but build your own, not changing/adapting your architecture to the changes (gradual or abruptly) in the world around us.
• Testing form, e.g. a decision to not do automatic testing, while testing the system by hand is to complex or takes to much time, to conclude after testing that everything is OK.
• Deployment form, e.g. when a deployment is arranged in such a way that it costs a lot of time and is error prone, thus limiting the number of releases in a period in time.
• Documentation form, e.g. it is unknown how the system should react in certain situations because it is not functionally described. This makes future functional wishes time-consuming to fulfill.
• Functional form, e.g. by business requested and by the development team invented functionality that is not really needed and makes things unnecessary complex for the upcoming change.
• Project form, e.g. distribution of experienced people vs. not experienced people in your team, same applies to skills in the team, onsite/off-shore team distribution, etc.
• Organizational form, e.g. not asking your software (application) provider what kind of quality assurance policy they apply and if they can provide any quality figures based on a ISO maintainability-standard.

All these technical debt forms result in less changeability, more costs and delay in bringing new features life. All forms can be plotted on the TechnicalDebtQuadrant of Martin Fowler. Whether technical dept is categorized as deliberate, inadvertent, reckless or careful, it is good to be aware of this and see how you want to cope with it strategically.
Conclusion
Technical debt is not only technical and has several forms other then code form.  The metaphor “technical debt” is invented to visualize the problem of decreasing productivity in the life cycle of the software product. People  can communicate with the metaphor more easily about the problem it addresses. This way the concept became known by development community, and unfortunately less known in other areas listed above.
Management familiar with the metaphor, can use it as an advantage by making strategic decisions regarding technical debt, because they understand the concept of normal debt. But for strategic decisions the management should be aware how much technical debt there currently is (like a normal debt) and the chances of a technical credit crunch leading to possible technical bankruptcy….
So is technical debt only technical. No, it is not.