In the previous article, we discussed how to measure and control technical debts. This article is to understand how technical debts get introduced and how to decide which technical debt needs immediate attention.
Another way to look at the cause of technical debt:
Let us extract the quadrant of technical debt alone and understand what happens there from the above quadrant.
Technical Debt quadrant (by Martin Fowler)
There is no concrete answer to the question, "Are all technical debts bad?"
If we take the technical debt quadrant as a reference, then the debt on the left side could be bad debt, and the one on the right is good.
It is about choices to make as a development team.
Let us take a more in-depth approach to this.
Ward Cunningham described technical debt as "the engineering trade-offs that software developers and business stakeholders must often make to meet schedules and customer expectations."
If we consider the above technical debt quadrant, then:
The Reckless Unintentional is the least looked-for. Since the team has no choice about incurring it and either does not recognize it or cannot correct it once it exists.
The Reckless Deliberate. This kind of debt occurs when the team knows a better way of the developing system but consciously trade-off quality by choosing a "quick and dirty" fix to a system for speed.
It mainly applies to the system or Product against short-term deadlines, but this should be prioritized for refactoring for the Product's longer-term behaviors. Sometimes there are no choices to this, and in that case, this can be considered the right approach.
The Prudent Deliberate. This kind of debt represents quality shortcuts, or a better word could be the workarounds made consciously by the team because of an immediate deadline. The team does know the consequences of shortcuts, and issues most likely take their place in the Product Backlog.
One can observe this in the work driven by SLAs. Their teams must choose to deliver something rather than focus on quality at this time.
The Prudent Deliberate. This kind of debt represents learning made by the team as the work is done on the Product.
This learning may result in the team's realization of the completed work, that if they had designed it differently, it might have resulted in a better quality Product.
The outlier between the implemented design and the ideal creates this accidental or unintentional technical debt.
Because the team did not intentionally create it, however, the team has improved its technical and Product understanding, and hence, it is under the Prudent (good) category.
Let's end this article here and leave the choice to the development team about what is their state of mind when they make difficult decisions of quality for time on their Product Development.
Find Our Upcoming Training
