The term Technical Debt has been wildly successful.
Ever since it was first introduced by Ward Cunningham in 1992 (Ward Cunningham, “The WyCash Portfolio Management System”) Technical Debt has grabbed the collective consciousness of the software development community and has functioned as a label applied to all the different kinds of technical shortcomings we can imagine.
The first version of Technical Debt is the one originally described: taking a conscious decision to postpone a change in the structure of our system, the need for which was triggered by new functionality, to facilitate a faster time to market. This does not mean that we have bad code, or skipped testing the new functionality, it just means that the structure of the code doesn’t quite resemble the mental model of our domain as much as it could. The key word here is conscious, this is not an accidental slip in quality, but an intentional trade-off of time to market and quality.
The second version of Technical Debt is one that we more often encounter in practice and one I would describe as: taking a conscious decision to postpone applying known industry best practices while developing new functionality to facilitate a faster time-to-market. The key word conscious is still there, but instead of just allowing the structure of code to fall behind on the model, we decide to also let other quality practices deteriorate. We might not write the same unit and integration tests that we normally would. We might not document the changes in the API that we make in as much detail, or at all. We might depend on some manual deployment steps instead of automating them. We get some short-term benefits by skipping those steps, so the CEO can show a carefully scripted demo at the trade show, for instance, but as with the first version we take on debt that will slow us down if we don’t pay it off.
There’s a third way in which the term Technical Debt is used, and it is the one that might be the most prevalent of the three. The actions are mostly the same as in the first two, combined. The difference lies in the word conscious. Where the conscious choice to skip a recognized way of working to achieve high quality, incorporating a plan to correct the flaw, is not done. There’s no discussion to skip a step for this time only, because of special and incidental pressures. There’s just, to use the technical term for it, the tendency to make a mess.
To summarize, Technical Debt can be:
- Good quality code, consciously deciding to temporarily not update the design
- Bad quality code, consciously deciding not to use good development practices for perceived speed
- Bad quality code, no conscious decision, AKA “making a mess of it”