I am an experienced software development manager, project manager and CTO focused on hard problems in software development and maintenance, software quality and security. For the last 15 years I have been managing teams building electronic trading platforms for stock exchanges and investment banks around the world. My special interest is how small teams can be most effective at building real software: high-quality, secure systems at the extreme limits of reliability, performance, and adaptability. Jim is a DZone MVB and is not an employee of DZone and has posted 91 posts at DZone. You can read more from them at their website. View Full User Profile

Don’t Take the Technical Debt Metaphor Too Far

02.05.2013
| 8216 views |
  • submit to reddit
Because “technical debt” has the word “debt” in it, many people have decided that it makes sense to think and work with technical debt in monetary terms, and treat technical debt as a real financial cost. This is supposed to make it easier for technical people to explain technical debt to the business, and easier to make a business case for paying debt off.

Putting technical debt into financial terms also allows consultants and vendors to try to scare business executives into buying their tools or their help – like Gartner calculating that world wide “IT debt” costs will exceed $1.5 in a couple of more years, or CAST software’s assessment that the average enterprise is carrying millions of dollars of technical debt.

Businesses understand debt. Businesses make a decision to take on debt on and they track it, account for it and manage it. The business always knows how much debt they have, why they took it on, and when they need to pay it off. Businesses don’t accidentally take on debt – debt doesn't just show up on the books one day.

We don't know when we're taking technical debt on

But developers accidentally take on debt all of the time – what Martin Fowler calls “inadvertent debt”, due to inexperience and misunderstandings, everything from “What’s Layering?” to “Now we know how we should have done it” looking at the design a year or two later.

"The point is that while you're programming, you are learning. It's often the case that it can take a year of programming on a project before you understand what the best design approach should have been."

Taking on this kind of debt is inevitable – and you’ll never know when you’re taking it on or how much, because you don’t know what you don’t know.

Even when developers take on debt consciously, they don’t understand the costs at the time – the principal or the interest. Most teams don’t record when they make a trade-off in design or a shortcut in coding or test automation, never mind try to put a value on paying off their choice.

We don’t understand (or often even see) technical debt costs until long after we've taken the costs on. When you’re dealing with quality and stability problems; or when you're estimating out a change and you recognize that you made mistakes in the past or that you took shortcuts that you didn't realize before or shortcuts that you did know about but that turned out to be much more expensive than you expected; or once you understand that you chose the wrong architecture or the wrong technical platform. Or maybe you've just run a static analysis tool like CAST or SONAR which tells you that you have thousands of dollars of technical debt in your code base that you didn't know about until now.

Now try and explain to a business executive that you just realized or just remembered that you have put the company into debt for tens or hundreds of thousands of dollars. Businesses don’t and can’t run this way.

We don't know how much technical debt is really costing us

By expressing everything in financial terms, we’re also pretending that technical debt costs are all hard costs to the business and that we actually know how much the principal and interest costs are: we’re $100,000 in debt and the interest rate is 3% per year. Assigning a monetary value to technical debt costs give them a false sense of precision and accuracy.

Let's be honest. There aren't clear and consistent criteria for costing technical debt and modelling technical debt repayment – we don’t even have a definition of what technical debt is that we can all agree on. Two people can come up with a different technical debt assessment for the same system, because what I think technical debt is and what you think technical debt is aren't the same. And just because a tool says that technical debt costs are $100,000.00 for a code base, doesn't make the number true.

Any principal and interest that you calculate (or some tool calculates for you) are made-up numbers and the business will know this when you try to defend them – which you are going to have to do, if you want to talk in financial terms with someone who does finance for a living. You’re going to be on shaky ground at best – at worse, they’ll understand that you’re not talking about real business debt and wonder what you’re trying to pull off.

The other problem that I see is “debt fatigue”. Everyone is overwhelmed by the global government debt crisis and the real estate debt crisis and the consumer debt crisis and the fiscal cliff and whatever comes next. Your business may be already fighting its own problems with managing its financial debt. Technical debt is one more argument about debt that nobody is looking forward to hearing.

We don’t need to talk about debt with the business

We don’t use the term “technical debt” with the business, or try to explain it in financial debt terms. If we need to rewrite code because it is unstable, we treat this like any other problem that needs to be solved – we cost it out, explain the risks, and prioritize this work with everything else. If we need to rewrite or restructure code in order to make upcoming changes easier, cheaper and less risky, we explain this as part of the work that needs to be done, and justify the costs. If we need to replace or upgrade a platform technology because we are getting poor support from the supplier, we consider this a business risk that needs to be understood and managed. And if code should be refactored or tests filled in, we don’t explain it, we just do it as part of day-to-day engineering work.

We’re dealing with technical debt in terms that the business understands without using a phony financial model. We’re not pretending that we’re carrying off-balance sheet debt that the company needs to rely on technologists to understand and manage. We’re leaving debt valuation and payment amortization arguments to the experts in finance and accounting where they belong, and focusing on solving problems in software, which is where we belong.

Published at DZone with permission of Jim Bird, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bruce Wallace replied on Wed, 2013/02/13 - 8:52pm

I totally disagree that "technical debt" should not be uttered in front of the "business" people.
That metaphor was created to get across to non-technical people that current decisions are replacing one kind of cost today with other kinds of costs in the future (without having to get into any technical details). Technical debt translates to real money, and to the extent that you can't put a reliable dollar figure to it, how many dollar figures attached to development estimates are worth the paper they are written on anyway! ;-)

When business is driving short term thinking with regard to costs, the business has to be made aware that there is no free lunch.  E.G. not spending the time/money to produce good specs now, will result in costly wheel-spinning later when QA misinterprets what should be tested, and when design/implementation has be refactored (euphemism for you-have-to-pay-for-it-again) because it didn't meet the business owner's desires. E.G. if you don't clean this code up now while we are in there anyway, you will more than pay for it later in maintenance costs. Etc, Etc.


Jim Bird replied on Thu, 2013/02/14 - 10:44am

 I'm not opposed to explaining to having conversations with the business about technical debt problems and risks and costs. The people who are paying for the work need to know when the development team has to stop and take time to rewrite some code because it is too unstable or upgrade some software to stay on support, and the potential costs and risks of not doing this work. But I don't think that developers should explain this in terms of debt to the business, and I especially disagree with people who come up with fancy technical debt financial models and calculators in order to push some agenda.

The "Technical Debt" metaphor was not created to explain technical issues to the business - it is a high-level metaphor to help technical people think about and talk about problems with a system that aren't bugs. Debt doesn't have the same meaning to the business, and it's a mistake to think this.

Matthew Holford replied on Fri, 2013/03/29 - 9:52am

I recently put up a related article at On Technical Debt, and just found this one, which makes many of the same points that I do (but a month earlier!). Thank you for contributing this critical look at the limits of the metaphor, and the real dangers of its misuse.

I've also written elsewhere on the issue of technical debt and "the business", and subsequently had conversations on this topic with engineering and project managers at different kinds of organizations, including Google, 10gen, and agencies. The consensus has been that technical debt as a metaphor, when explained correctly, brings clarity of conversation across groups, including business, and helps disparate actors to find resolution on sometimes hairy conflicts.

While I agree that the metaphor was "not created to explain technical issues to the business," the point is that we benefit the larger organization when all groups gain fluency with this term. There's no need to be an originalist about the metaphor and its intended audience. Those of us who understand the metaphor in its historical and technical context have a responsibility to educate others as to its responsible use. My employer has seen potential clients actually breathe sighs of relief when our project managers display a knowledge of the metaphor, and in particular what it means in the context of an engagement that, e.g., seeks to push new features onto an aging, complex platform. These kinds of conversations can be greatly enabled by a nuanced understanding of the metaphor's use, and of its limits.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.