Dissecting Technical Debt

The term "technical debt" was coined by Ward Cunningham. It describes the obligation that a development team incurs when it chooses a design or construction approach that is easy to implement in the short run but has a larger negative impact in the long run. Agilists provide their view point on what should be considered a technical debt and how it could be classified.

Martin Fowler suggested the following definition for technical debt,

Technical debt, is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

Steve McConnell classified the technical debt into two kinds,

• Unintentional – Junior developers writing bad code because of their inexperience.
• Intentional - Team makes a conscious decision to optimize for the present rather than for the future by making some design choices which may be a quick and dirty way of resolving the situation.

Uncle Bob, added that sometimes mess is also considered to be technical debt. This is not correct. According to him,

A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss.

Uncle Bob suggested that technical debt creates a need for cleanliness in the code, just like one needs to be more disciplined when he takes a big mortgage debt. He added that once the team decides to take a technical debt, it becomes all the more important to keep the code squeaky clean. Unless, this is done the situation might quickly disintegrate and paying off the debt would be a harder challenge.

Martin Fowler gave his view point that a mess is also a technical debt albeit of a different kind. He described mess as a reckless debt which results in amplified challenges as compared to a prudent debt which is based on well calculated situation. He further classified the technical debt as deliberate and inadvertent to complete the quadrant.

Martin gave the following examples for classifying technical debt into quadrants

1. Reckless - Deliberate – The team does not have time for design and provides a quick and dirty solution with little foresight into quality.
2. Prudent - Deliberate – The team must ship the product now with the known shortcomings and take a proactive lead on the consequences.
3. Reckless - Inadvertent – The team is unaware of the basic design principles and hence does not even realize the mess that they are introducing.
4. Prudent - Inadvertent – This is true for teams with excellent designers. They deliver a solution which is delivering business value but after completing the solution, they understand what the best design approach could have been.

Thus, having a technical debt in a project is usually inevitable and should be considered to be an expectation. The key lies in making sure that a team is not introducing reckless debts which contribute to the mess and are very difficult, if not impossible to deal with.