Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
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,
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
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.
Agile Development: A Manager's Roadmap for Success
Learning to be a Good Product Owner: Foundation Skills
Design in Agile, Software Craftsmanship, Product Development, Testing @ QCon London in March
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
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?
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
5 comments
Watch Thread Reply