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.
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.
- 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.
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
- Reckless - Deliberate – The team does not have time for design and provides a quick and dirty solution with little foresight into quality.
- Prudent - Deliberate – The team must ship the product now with the known shortcomings and take a proactive lead on the consequences.
- Reckless - Inadvertent – The team is unaware of the basic design principles and hence does not even realize the mess that they are introducing.
- 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.
Messes happen for more reasons than inexperience
It's a management problem, really.
Jeroen van Bergen
A clean rewrite of a 1.0 version might be expensive, but the lessons learned during the first development cycle will improve quality considerably. But the merits of this will only be visible in the long run. A lot of software is judged only on functionality, not on maintainability or adaptability.
And lets not forget how hard it is to write really good, bug free software. One of my favorite examples is how even the IEFBR14 program (en.wikipedia.org/wiki/IEFBR14#History_from_the_...) was incorrect in some ways. The story about IEFBR14 also illustrates that improving software is an evolutionary process. More modern techniques like refactoring have speeded up the process, but the basis is still the same.
Best definition I've seen of technical debt...
Re: Best definition I've seen of technical debt...
The best definition of TD that I've seen is "the difference between what the code is and what the developers think it should be." ...
Jason, I find your definition to be too loose. It allows developers to make changes based on their biases and not on the ease of changeability of the code, which is what Ward was after. Consider a code base that is correct, DRY, uses Information Hiding correctly, has a test suit and a complexity measure of 2.6, see Keith Braithwaite's work on impact of Unit Tests on complexity and the problem with it is that for the current set of developers it was implemented to use Smoothsort instead of Heapsort which they are familiar with and so they wanted to change it, even though they had no requirements to make changes in that part of the code base. This example is based on a true situation I observed, with details changed to protect the innocent.
Technical Debt is about the economic cost of future development and if the definition one uses does not include this then it misses this point and does not provide a way for those involved to make decisions appropriately, see The Principles of Product Development Flow. So any Technical Debt definition needs to prevent changes based on developer biases that do not reduce the cost of future changes.
Re: Best definition I've seen of technical debt...
I defined it by saying ...
"Technical Debt [a.k.a. Design Debt] occurs when our software becomes difficult or risky to change, and takes increasingly more time/effort to evolve.
Technical debt represents the accumulated amount/cost of rework that will be necessary to correct and/or recover from the deviation between:
* the current design of the system, versus ...
* a design that is minimally complex yet sufficiently complete to ensure correctness & consistency for timely delivery.
This effort grows more than linearly over time as a system becomes bigger and more complex."
I think this manages to synthesize the definition that Jason liked so much while also addressing the issue the Norbert raised. Do you agree?
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014