Is Technical Debt Still a Useful Metaphor?

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?