New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Dissecting Technical Debt
Posted by Vikas Hazrati on Oct 20, 2009
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
- 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.
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Five Key Practices to Agile ALM
SCM best practices for multiple processes, releases & distributed teams
Related Sponsor
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Messes happen for more reasons than inexperience
by
peter weissbrod
Posted
It's a management problem, really.
by
Jeroen van Bergen
Posted
Best definition I've seen of technical debt...
by
Jason Reid
Posted
Re: Best definition I've seen of technical debt...
by
Norbert Winklareth
Posted
Re: Best definition I've seen of technical debt...
by
Brad Appleton
Posted
-
The above article implies that the blame for a mess always falls at the hands of the developer, but sometimes its not that simple. I have seen talented developers with over a decade of experience deliver "high-debt" solutions. Why? Inefficient solutions can come from poor cross-team communication and poorly executed up-front analysis. If your specs have oversights in terms of efficiency, then it will likely reflect in the code.
-
This is just another manifestation of the usual trade off between quality, time and functionality. A team under pressure has to make decisions on what to sacrifice. Usually quality is dropped first, incurring the mess that we all know and love.
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. -
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." This acknowledges that technical debt can accrue even if the developers always "do the right thing". All it takes is for them to learn something new and have the realization that the code should look different, and they've accrued technical debt. This kind of situation happens often, for example, when a new version of a library or framework is released and the developers feel it should be incorporated to their software.
-
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. -
I blogged somewhat comprehensively on the subject of Technical Debt and included a fairly thorough list of hyperlinks and references over at Technical Debt - Definition and Resources
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?
5 comments
Watch Thread Reply