Is Technical Debt Still a Useful Metaphor?

| by Amr Elssamadisy on Jul 11, 2011. Estimated reading time: 4 minutes |

Technical debt, coined by Ward Cunningham, is:

Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

A discussion has been taking place on the LinkedIn Agile Alliance group questioning if "technical debt" is still a valid metaphor in today's global software development world.  Marvin Toll started off the discussion saying:

After almost twenty years perhaps we now have sufficient experience to observe if the metaphor remains effective. My observation? "Not Useful" In an increasingly global IT community with English as a second language, and an attention span of 140 characters, the nuances of the metaphor no longer serve application development well.
Said another way, the conversation around poor quality code gets bogged-down in explaining the financial use-case.

Most people came out in defense of the term and its importance in making people aware of an oft-overlooked but expensive problem.  Daniel Nelson shared what he felt is the danger of people not being familiar with the term:

From my years of programming, then Business Analysis, and now CSPO, I find it dangerous if agile team members don't have at least a rudimentary understanding of technical debt (regardless of what it may be called in your particular environment) as well as the more common causes and cures of this debt.
Without explicit practices in place to prevent it, Technical Debt can and will grow out of control to the detriment of the software. Code will become buggy and fragmented and interfaces will feel disjointed.

I like all of the metaphors used here and think that whatever is adopted is fine, so long as something is used to keep this issue in the minds of the teams.

 Steve Gordon pointed out that metaphors can co-exist:

Metaphors are just models, but using other common concepts instead of mathematical terms or drawing conventions. Like all models, metaphors illustrate some aspects and ignore other aspects.
The technical debt metaphor illustrates the growing costs of bad code. It is not intended to illustrate what bad code is. ... Multiple models or metaphors can coexist without conflict, especially if they illustrate different aspects or make better sense to different people.

And Curtis Stuehrenberg, a QA manager, explained why it was an important term for him in his role:

I personally like the term since the discussion about it tends to elevate topics and conflicts normally glossed over in standard project teams. No matter what sort to team you are on, there will always be tension between doing the infrastructure things you know need a-doing and the flashy-shiny things your sales team knows they can sell for more money. If you watch home improvement shows the tension is similar to that of a house flipper attempting to spruce up a home before reselling it. Every day the house is off the market, the flipper is losing money either in direct carrying costs or opportunity costs based on the capital that might be otherwise invested. This causes the flipper to want the project to take the least amount of time possible. They also want to put the least amount of investment into their property they can in order to maximize their ROI.
If you watch closely, you'll see experienced flippers do everything they can possibly do to avoid doing things like opening walls or crawling under floors. The experienced flipper knows as soon as they do this, they are statistically likely to find something they have to repair for structural or safety reasons or else have to legally disclose the fact it's a hazard to a potential buyer.

Technical debt in a project are the things lurking behind the walls, under the floorboards, and inside the roof lines of the house we just bought to turn around and flip. Most teams will make heroic efforts to NOT crack the original source code because they know as soon as they do they'll open a giant can of expensive rework. And just like houses, the older the code base the most likely you'll find knob & tube wiring or asbestos or lead paint.

That's why I like talking about "technical debt" as a QA person. If we just come out and say we're fantastically nervous about checking around the skylight because we're pretty sure we'll find black mold then we can rationally weigh the risks and select a mitigation strategy we can all live with. Not talking about it just means some one is being fitted for a new company shirt with a giant target stitched into the back.

So, is technical debt a good metaphor?  It seems that it still works for most people, as long as it does no harm.  It may not be appropriate for all cultures and all teams, and that is acceptable because metaphors can co-exist.  Does this match your experience?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

90% of code is bad code nowadays by Adam Nemeth

We have two options:
a) Accept that as long as the sh.t is shippable, we don't care. Consecutively, accept that university diplomas are only toilet papers as we don't deliver quality, we are craftmen, which means anyone who plausibly claims he understands how to make code which seemingly does what it was asked to do qualifies. After all, usually, no matter how high quality was the original design, the whole system will be thrown out with disgust after 5 to ten years anyway, and even the second generation of developers won't care about our initial reach for beauty anyway, in the midway of that 5-to-10-years.

b) We start to systematically persecute such behaviour, require engineering thinking, where customer (and project manager) demands were only secondary after fulfilling internal stability issues, like the customer's opinion is only secondary if it threatens the stability of a building. We start to form committees which question the ethical workings of an engineer, persecute engineers in case of system collapse, and revokes license to work.

Currently, our profession is much more into a) than into b) I guess.

Technical Debt doesn't make sense when your whole software is a debt in itself, growing every day, and you wish all day to rewrite it, but you're requested to add just another 200 lines to a file today.

The metaphor still hods for whomever wants to understand it by Augusto Rodriguez

I work as a consultant and I'm amazed at some of the clients I've worked for. Some of them use the Ostrich Defense, completely ignoring everything related to technical debt and quality in general, because they are so constrained (usually by their parent company) that "adding the extra feature quick and dirty" will keep the project running for another month ... and more money for the pockets of the CEOs or senior management. This, of course, is self defeating and after some time these companies are closed down or sold for pennies. This rarely works and usually ends in a blame game.

On the other hand, some companies motto is "quality and customer satisfaction" and technical debt has to be paid ASAP. These companies also know that if they want to survive in the long run, they need to keep the product "habitable". Of course this doesn't ensure that the company or project will be successful, but in my experience this projects have far more chances to succeed in the long run than the other type.

Re: 90% of code is bad code nowadays by Amr Elssamadisy

So Adam, did this post set you off or are you down on software development in business in general? What do you think might be a solution for these problems?

Re: 90% of code is bad code nowadays by Adam Nemeth

Dunno, I've just left one of the major IT companies and I don't want to see IT until september, but even then I'm dubious if it's really for me...

bad code is not technical debt by Saad Khawaja

well at least as Ward explained it here Technical debt is difference in the design/model from one model to the next, which happens due to a learning/discovery. The failure to roll the learnings into the implementation is debt. This causes friction between the model and the implementation because they are out of sync. This friction is the interest that you pay. Compare this with the technical debt that folks seem to confuse with. Quick/dirty, bad coding is not technical debt because it does not necessarily accrue interest as Ward's Technical Debt does.

Re: bad code is not technical debt by Saad Khawaja

yes it is by Saad Khawaja

oh btw yes it is very useful if we can measure it(both the debt and the interest) and communicate to the product owner.

Re: 90% of code is bad code nowadays by Tester Testersson

You are right but it doesn't matter anyway.

The problem is that high quality is no longer the main requirement for IT projects nowadays. It's all about low costs and (what's perhaps even more important) rapid development to fill some market niche.

The investors won't care for quality as long as the system just works and gains them profit.
<rant>You can't really blame them - usually they're just MBAs who don't understand that IT systems are not just about pretty GUIs.</rant>

Re: 90% of code is bad code nowadays by Steve Ropa

Couldn't those same MBA's say we are just a bunch of nerds who don't understand that the financials are what keep us paid? This is why I like the technical debt metaphor so much. It gives the MBA's a language that they can grok to explain why they are way better off being willing to pay for the high quality software.
Also, having known a lot of MBA's in my life, I chuckle at the phras "*just* MBA's". MBA is an extremely challening, and yes technical, degree.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss