I dislike the term Technical Debt

 

5 or so years ago a manager at my company, Leon Messerschmidt, gave a talk to our engineering department called “Why I don’t use the term Technical Debt and you shouldn’t either” and since then I’ve wanted to write my own view on this. Before then I had felt uncomfortable with the term, it seemed very subjective. In the talk Leon described how the term debt was often viewed as a good thing by people with a financial background (as he had) and so gave the wrong impression to non-engineering stakeholders. What Leon advocated for was instead a “Tidy as you go” approach, which reflects a lot of what Kent Beck went on to describe in his series of blog posts and book:

If you only have a minute to read, here are the classic software design blunders:

• Thou shalt not rewrite the whole system.

• Thou shalt not pause delivery of features for an extended period to fix the design.

• Thou shalt not delay the first feature to "get the design right".

• Thou shalt not thoughtlessly demand the next feature immediately upon completion of the last.

The problem with Technical Debt is it’s used to justify the first three blunders. This leads to all kinds of poor outcomes; the one I find the most pervasive and problematic is the polarisation that occurs when the conversation turns to code quality. Technical debt and code quality often go hand in hand and it leads to conversations that are largely removed from the people who use and benefit from the software produced. Sometimes we call these people users, customers, stakeholders or “the business”, but separating the groups can reinforce the us-vs-them mindset. I don’t mind these terms, they are useful in specific contexts, but we need to ensure we use the right language to represent what people want. Stakeholders and customers don’t want code quality, but they often do want reliability and flexibility. Quality for the sake of quality is wasteful and drives a wedge between developers and stakeholders.

The approach of using Quality Attributes allows us to express properties of a system with language that reflects the needs of users and stakeholders while expressing the engineering aspects; if we need features to be delivered quickly and to keep maintenance costs down then that needs to be factored into the design and estimations. This contrasts with the purely engineering language like refactoring, code quality and technical debt which fail to quantify the impact on non-developers. Using quality attributes has other benefits, it provides a taxonomy to clarify requirements so that they can be more clearly communicated.

Problems still arise when the goals of different parties are not aligned, if your compensation and promotions incentivise conflicting goals, such as delivering features vs. maintenance costs, then you’re still going to end up with conflicting priorities. The fourth blunder in Kent Beck’s The Surprise Factory, “thoughtlessly demand(ing) the next feature immediately upon completion of the last” is often due to these conflicting incentives, but can also be caused by impatience and mis-management. That’s a topic for another time.