DevOps Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at http://www.gilzilberfeld.com and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Technical Debt: I Do Not Think It Means What You Think It Means

11.04.2012
| 12688 views |
  • submit to reddit
Here’s another example of why language matters, and how the words we choose matter so much.

I tried to join the European Lean-Kanban tour, not in person, but on twitter. (By the way, seems like an awesome tour, I’m thinking about going there next time around). And then the following tweet comes up:

"@cyetain: Talking to @DReinertsen at #lkfr12 he prefers "Deferred Work" to Tech Debt Metaphor. I think it is a bit clearer too..."

Before I give my interpretation, I give thanks to Jabe Bloom, who tweeted like crazy and made me feel at home (online) and for reporting this tweet (and giving birth to this blog post by proxy:)). And Don Reinertsen, I’m gaining more respect for everyday.

Now that the niceties are out of the way…

Technical Debt or Deferred Work?

When developers talk about technical debt, the words say: There’s some technical stuff we left out, which will come back to bite us. The refactoring we didn’t do will cost us when we’ll enhance that feature. Those tests we skipped writing, are going to cost us in regression bugs.

Note the economic jargon: The debt is an economic one, NOT technical. That’s no coincidence. Economics is a better way to persuade managers to listen to developers.

There’s also an emotional nuance in the term. When we’re taking on technical debt, we, developers, are carrying the cross for the company. Not only that, we take the blame, and know we’ll pay the price later. Or we can translate it to: We’re warning you, managers, this “joint” decision is on your head.

From the manager’s side, things look much clearer: We’re always prioritizing stuff. We can’t do everything we want, and things get dropped. So in the upcoming release, we’re going to drop these pesky technical things we don’t really understand. We do understand there are associated costs and risks (as the developers tried to explain), and we’re ready to decide.

We’re really deferring work. This is a business decision.

Not Just Words

Agile started as a solution to a problem: building a bridge between developers and the business people. The bridge is built on trust. Trust is built on communication. When we use charged words on one side, or disregard this emotional charge from the other side, we’re adding cracks to the bridge.

A few cracks will not break the bridge.

What do you think happens when there are many of them?

Published at DZone with permission of Gil Zilberfeld, 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

Cristian Vasile... replied on Mon, 2012/11/05 - 12:25pm

"Technical debt" is the correct term. The word debt carries with it the meaning that sooner or later you need to pay the interest and the longer you wait the bigger the interest. Managers need to understand this. And as with a bank, you might decide to take a loan. But just as you wouldn't take a loan without knowing how big the interest will be, so a manager shouldn't decide to postpone things unless he really understands the associated debt and decides the loan is worth it anyway (yes, there are such cases but somewhat rare, I would say).

"Deferred work" is really a misnomer because it gives the impression that I can do the same task later with the same amount of effort/money and without any associated debt to pay.

Manager that don't understand technical details should either trust developers on these things or quit being managers (or learn technical details).

Too many times managers believe developers just want to make code pretty, not understanding the concept of debt (translated in both increased difficulty/time/costs to implements new functionalities and also increasing number of bugs).

Brian Shannon replied on Mon, 2012/11/05 - 3:35pm

Another way I've phrased technical debt to developers is that it is "a conscious decision to insert or leave a WTF in your code."  :)  It's not quite the same, I know, but it speaks to developers a bit more.

Thomas Bernhardt replied on Mon, 2012/11/05 - 4:24pm

 Unrelated: the article has a picture from a movie, what movie was that please?

Cristian Vasile... replied on Tue, 2012/11/06 - 1:22am in response to: Brian Shannon

 Funny and true at the same time... :)

Gábor Lipták replied on Tue, 2012/11/06 - 3:41am in response to: Thomas Bernhardt

replied on Tue, 2012/11/06 - 5:58am

I agree with @Christian that  it is technical debt and not a deferred task. There is interest to be payed on the debt when deferred, in fact it also gets compounded as time passes.

Such interest on Technical debt comes in various shapes and forms a couple of which were mentioned:
  - More complicated and thus more expensive to add features in the future.
  - Greater likelihood for bugs thus reduction in quality.

Another subtle impact of technical debt is that it acts to demotivate your best team members. Technical debt is an indicator of (lack of) quality often the route cause is down to an attempt to meet an arbitrary business deadline.  When devs are not allowed to technically create the correct solution and have to face the consequences of such decisions in later iterations, they can get demoralised and be prepared to leave to a competitor that cares more about quality.

Allowing technical debt to grow is a business risk, it is not a collection of deferred tasks.

Riccardo Cossu replied on Tue, 2012/11/06 - 7:06am in response to: Cristian Vasile Mocanu

I absolutely agree with you; "deferred work" does not give a clue about "interest".

As developers I think we need to tell managers that feature X could either cost 10 upfront or 5 now and 5 for the next 6 months (or more); if they do not trust/understand us I agree they should quit managing and surely don't deserve we do overtime because of their short sight.

Lund Wolfe replied on Thu, 2012/11/08 - 4:35am

My opinion is that "technical debt" implies some sort of bad judgement or incompetence on the part of the technical team.  I would even include bad requirements as technical debt which may just be from different members of the team.  It is equivalent to letting less competent developers do the work now and hope that it works out or can be fixed (at a much higher cost) later.  It will degrade exponentially over time, so get it right the first time.  As a software professional you are expected to do quality work (or at least your best).  Don't give short cut options to nontechnical people and expect them to make the judgement call in your area of expertise.

Trade features for features or reduced features.  You can make it faster and cheaper by making less of it (at least for now), but don't make it bad by trading quality for technical debt.

Nicolas Bousquet replied on Sat, 2012/11/10 - 5:33pm

The idea with the technical debt as we use it is that good code has low cost and that bad code has a huge cost.

And this not a concept of debt. This is more a concept of investment. We found this in capitalism. The more you put into your capital the more your capital produce.

A software should be an investment. It produce you some benefit that justify its existance. And hopefully the more you invest into it, better the result.

But like in classical economy, investment has a cost, and justify it cost only if you have the use for it; And like many investiments, it depreciate with time. It need repear... One day you it simply outdated or nobody care about what it can do anymore.

The question of much to invest, and for the concept of technical debt, what should be the quality of what you invest in is complex. And this is not that you should spend the biggest amount possible and buy the best quality possible. Or even replace by the best quality what you already have.

Having the perfect software with perfect code and no technical debt is like always buying the latest mobile phone. You just need to make a few phone call, but you always have the latest iphone. Because it is better. Only result if that you have a huge cost center for a low value in return.

As engineers, we tend to think that our craft should be perfect, using latest and greatest. But this is expensive, and bring little value in the short term. Even in the long term if it depreciate too fast or if there is no enough use, this is not worth the investment.

The company should instead find good compromise and know when to say yes or no.

Gary Pavek replied on Wed, 2012/11/14 - 10:32am in response to: Thomas Bernhardt


The movie is The Princess Bride. The character shown is Inigo Montoya (played by Mandy Patinkin). The title of the article comes from one of that character's most famous quotes.

Caspar MacRae replied on Tue, 2012/11/20 - 8:09am

 http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ (but read Kevlin Henney's comment).

Debt is a better word as it permits bartering with management.  "I'll give you features X,Y,Z by the end of this sprint, but in the next one you'll owe me 3 days of refactoring/retroactive testing etc".

As others have pointed out; Interest on debt increases over time - this is fundamental concept that all involved should appreiciate.

Adam Lucas replied on Wed, 2012/11/21 - 1:51pm in response to: Cristian Vasile Mocanu

 IMO, it's a 'taste great/less filling' argument;

"Technical Debt" is the potentially compounded cost of an unimplemented or incompletely implemented concept.

"Deferred Work" is the fixed cost of implementing or completing the implementation of the same concept.

Denying the existence or use of the term 'Deferred Work' is synonymous with denying the existence of any other solution but yours. I have yet to meet a coder, myself included, who can ascribe $ or man-hours to technical debt in any fashion resembling fiscal debt. Untold amounts of technical debt have been absolved by Moore's Law. Too many coders have insulated ideas about their code living forever or the product/market will never changing (or the flip side; that their code needs to be, or their customers demand, the latest and greatest). Some businesses are really successful refactoring or churning their code, some are successful leaving it be, most have to switch between the two.<br/>

The issue that (I think) the author was trying to make <i>is</i> the Miller Lite ad. You may think it your beer needs to taste great and your managers may think it needs to be less filling. However, if you can't agree that your goal is to sell beer for money and that there may be many ways to do that; you either need to come to an understanding (through communication), cease doing business together, or be forced to cease doing business together (How many different ways did Jobs nearly strangle Apple to death?). If reading/writing code made phenomenal managers and businessmen, the tech bubble wouldn't have happened and the overwhelming majority of businesses would be run by coders.

Caspar MacRae replied on Fri, 2012/11/23 - 7:11am

Seems to be a hot topic at the moment http://michaelfeathers.typepad.com/michael_feathers_blog/2012/11/staring-down-technical-debt.html

Comment viewing options

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