Consider the Tech Debt Quadrant to Classify Good and Bad Debt

There is an ongoing debate as to which design flaws should be classified as tech debt and which should not. It is not always tech debt when a code is in a mess. It can be the cause of ignorant people designing it but should not certainly be considered as tech debt. On the contrary, tech debt should be in those features in which the developers have taken deliberate steps to adopt a design strategy which may not be sustainable for the feature for a long time but will produce only short-term benefits. There may be pressure from the product owner or from the stakeholders to make an early release which results in such practices which must be paid off at the earliest.

Benefit of the Metaphor

Tech debt cannot be measured and hardly seen, and therefore it is termed as a metaphor. But the real question is not about the design flaw being tech debt or not; it is whether or not the tech debt metaphor helps in any way in the thinking process of dealing with tech debts. The ways to deal with it during the designing, ways to communicate that thinking to other members of the team should be facilitated by such methods. This is where the metaphor comes handy in communicating the effects, causes, reasons and usefulness of addressing it even to the non-technical people like the shareholders.

Nature of the Debt

The debt metaphor works well in both the case, but the actual difference lies like the debt. The mess in code can be a reckless debt which can cripple the payments of interest or even result in a long period required to pay down the principle. The debt metaphor helps in reminding the developers about the several choices available with design flaws. When it is seen that interest payment is considerably small, then a prudent debt for early release may not be useful when paid down. Therefore, the distinction should be between prudent and reckless debt and not between debt and non-debt.

Deliberate and Inadvertent Debt

Apart from prudent and reckless debt distinction, there is another distinction that should be made. It is deliberate and inadvertent debt. A prudent debt can be deliberate as the developers know that they are going on to take debt. They put some thought and balance between the payoff for any earlier release with the cost of paying it off and find which is higher. Any team which is ignorant of the design practices are constantly taking on reckless debt without knowing how much trouble they are getting into. To know more visit here.

Reckless Inadvertent Debt

Reckless debt may or may not be inadvertent as a development team may know about good designing, and the practices followed for it. They may also be capable of following it all the time but still decide to go dirty because they feel there is no time to write clean codes. They seem not to understand where the design payoff line is. All that is desired at the point is to go faster for which the team even compromise with the code design and quality.

Share on Facebook

Leave a Reply