Development Short-Cuts Are Not Free: Understanding Technology Debt

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Development Short-Cuts Are Not Free: Understanding Technology Debt


In my many years in the software business, one concept I have found to be pervasive is that of technology debt.  Technology debt is basically when you “borrow” time to avoid having to pay it now – but likely having to pay it later, generally with interest.  For example, when you decide that you have uncovered some design flaw in your software product, but “work around” the issue with a hack so you can meet the project deadline, you are incurring technology debt.  There is definitely a cost to this decision, you are simply taking on the cost because the cost of not meeting the deadline is much higher.  At least that’s what you believe (it may or may not be true).  You promise yourself that once the product has shipped, you’ll go back and “fix” it (and pay off that debt).
Technology debt is not unlike financial debt.  The most significant parallel is that of “interest” (i.e. when one incurs financial debt, there is an understanding that the amount you must pay later is higher than what you would have had to pay today).  However, financial debt in business is very rational and pragmatic and hence very common.  As long as you can create value from the cash you borrow today that exceeds the cost of capital, things are mostly fine.  Such is the nature of debt.  However, problems occur when you don’t generate this value and the debt becomes a larger and larger burden.  
When incurring technology debt, there are similar patterns, but the challenge is much greater.  Often, the interest rate is not known and can’t be accurately predicted.  So, when you take a short-cut this week on a major project so you can meet some deadline, and it saves you 100 hours – how much will you have to pay eventually (in the next 2-3 years) to overcome this debt?  What are the chances that your “loan” gets called before you anticipated it, and it comes at a time when you simply don’t have the resources (time) to pay it off?  I’ve had this happen to me before.  I’ve taken a short-cut on a project to save some time during a crucial deliverable, but ended up having to “pay it off” at a very bad time when I could ill-afford it.  
Also, there is a random “forgiveness” factor that occurs in technology debt that we don’t see in financial debt. This forgiveness factor is when you incur technology debt, but for whatever reason, it doesn’t really cost you anything because the project is abandoned for some reason or some other issue dominates the equation, and it just doesn’t matter.  In this case, you end up really not paying your debt at all.  However, it is this very “forgiveness” that makes technology debt so tempting and pervasive.  We often have this misguided notion that we can take these shortcuts and incur the debt as we may never have to pay it off.  In fact, many software development managers may be subconsciously thinking that they won’t have to pay out their debt anyways (as their successor or replacement will have to deal with the issue).  The net effect is that it causes more people to incur technology debt than likely would have occurred otherwise.
Understanding technology debt is difficult, but important.  At a minimum, it is important to understand when making “tradeoff” decisions, that in fact, you are incurring debt.  Awareness is the first step.  Then, try your best to assess the “interest rate” on the debt – or, what is the likely price you will have to pay in the long-run as a result of this decision.  In many cases, its worth it.  The interest rate is low compared to the “value” (in terms of shipping a product now) that you can incur.  But, often it is not -- and its better to pay now, than pay significantly more later.  I know of at least a few software companies that incurred so much technology debt, mostly due to poor management that they could not unbury themselves from it and it ultimately killed the company.  
My recommendation:  When making the classic tradeoff decisions in technology, make sure you understand the implications.  First, learn to separate the tradeoffs that will have to be paid off some day – and those that won’t.  Learn to approximate the “interest rate” so you don’t dig yourself into a hole you can’t dig yourself out of later.  Finally, when resources do become available, try to start paying off some of your old debts.  This can be done with things like code refactoring and replacing old proprietary code with new components that use open and established standards.  Just like financial debt, there is something very uplifting about cleaning up some of these old messes.  The trick is in knowing which debt to pay off.  Please don’t use this as an excuse to rewrite that old product simply because you think it should be rewritten.
One of the advantages that startups have over larger companies is that they can be more judicious about what debt they take on and suffer less from the “pass it on” syndrome.  As founder/CEO/CTO/whatever, in a startup you have some control over what technology debt you’re willing to take on.  The startups that thrive and succeed are the ones with leadership that understands this (implicitly or explicitly) and makes the right kind of decisions.  On a related note, many of the “built to flip” companies (if you look at them closely) routinely incur technology debt under the belief and hope that before it comes time to pay off their debt (that is fix their problems), they’ll be acquired anyways.  
Note:  This article is an edited version of an earlier article I wrote before was started.  

Posted by on Tue, May 23, 2006


I love the analogy you make between technology debt and financial debt. I think it's a very abstract concept, but does seem to hold some weight.

... but a bit of a dangerous idea for an entrepreneur making a startup. The assumption is that, making a larger than desired technology investment is going to result in a greater chance of success.

I'll cheer on the entrepreneur who racks up giant technology debts, but still gets the core idea right. Create something really wonderful, that works good enough. If it works, and it catches on, then worry about paying all those debts off ;)

posted on Tuesday, May 23, 2006 at 12:14 PM by danny

I can identify with what you say but am not entirely sure that is what you meant.

Some detailed examples from a variety of people would be a good idea. Complete with a costing of what happens.

Things that come to mind:

1) The easy and universal examples: Not documenting, not writing a full test suite / harness, not designing up front...

2) Then areas where the supports is atrocious (like some features in .NET 1.0 or capabilities in T-SQL). If you make a quick patch, there is a good chance that the hole will eventually be plugged and plugged better than you could.

3) ...

Not sure whether anyone will take up this idea. One idea might be forum threads, with developers doing real work like several people refactoring some code that is only part baked.

The other side is over-capitalised software. (Too much work...)

posted on Tuesday, May 23, 2006 at 8:10 PM by

Too extend your analogy, how much effort do most programmers spend on long-term investments like learning another language/framework? Or keeping a "checkbook register" of your technology decisions during development so you know where your "t-debts" are?

Of course the biggest "t-debt" is the mounting cost of trying to be connected to an ever-growing number of RSS feeds, Web Sites and web 2.0 apps!

posted on Tuesday, May 23, 2006 at 8:57 PM by Bob Walsh

Interesting idea and is true if the technology you are using is stable and non-changing.

However, if you are developing software using tools and libraries that change once year like ASP.NET or Java, I am not so sure.

However, I think the biggest problem is that start-ups develop too much code, at least for the first 1-2 years until your customers decides what is needed. So therefor, I think short-cuts is a good idea. When you start a start-up, ask yoursefl "How much of the initial program is actually used by many customers in 2-3 years time?"

posted on Sunday, May 28, 2006 at 4:55 PM by Mattias Waldau

Comments have been closed for this article.