Technical Debt

The term “technical debt” was first coined by Ward Cunningham in 1992 and describes the effects of maintaining poor or rushed code. It views projects with a financial mindset and compares the technical things we do and don’t do with the financial concept of debt.

On the one hand, technical debt refers to the quick and dirty shortcuts we take and the effect they have on future development. On the other hand, technical debt is also about the things that we don’t do, such as not commenting our code, not developing documentation, not doing proper testing, etc.

Where does technical debt come from (what causes it)? Wikipedia gives a nice list of reasons and conditions that can cause technical debt. But for my money, the main reason is pressure from someone in the business to get something done and get it done quickly. It might be your boss, it might be someone else’s boss, it really doesn’t matter. The number one reason is the same reason we did stuff in junior high – somebody else thought it would be a good idea and pressured us into it.

In the end, it’s the quick and dirty things we do and the things we neglect that put ourselves in debt with respect to future work. A short-term fix might make it harder to do something else in the future, or it might result in extra bugs and maintenance fixes. Not having documentation makes it harder for a new developer to get acquainted with a system and results in lost productivity.

Is Technical Debt Bad?

Technical debt is a bad, bad thing… or is it? Since we’re looking at this from a financial standpoint (at least in our terminology), then let’s take it one step farther. If you talk to any financial analyst they will tell you that reducing your personal debt is probably the best thing you can do for yourself. It’s hard to argue with that advice. At the same time, however, can you really imagine modern society running without some level of debt?

How many companies have zero debt? Probably none. The truth is, modern companies embrace debt as a fact of life, and most companies couldn’t exist without the ability to carry some level of debt. Obviously there is some ambiguity about debt when talking about financial systems.

The unstated assumption here is that while individuals may not be smart about their debt (hence the rule of thumb is that it is best not to have any), companies know how to manage a limited amount of debt intelligently. Of course, companies are just groups of people, so this probably doesn’t hold up very well.

But assuming some financial debt is okay, maybe even necessary to conduct business today (most companies, like most people, don’t have cash on hand to buy a new building or new machinery outright), is it also true that some amount of technical debt is acceptable, maybe even, dare we say, desirable?

Another View of Technical Debt

This is a very controversial point. If we recast the problem from a quality control point-of-view, then we’re asking whether it’s ever desirable to reduce the level of quality and inject a degree of scrap into our process. Put that way, the answer seems obvious. Whether or not your company (and you) pursues a zero-defect quality control policy, the idea of quality first is so ingrained in our corporate psyche that we could not sanction a process that didn’t adhere to that. That is, while we may not practice it, we’re all for it.

No matter what we say about quality when we sit in our wing-back chairs at the club, we all practice a flexible attitude towards quality just like we practice a flexible attitude toward debt. When we need to buy something that we think will make the business more successful but we don’t have enough cash in our wallets, we go into debt. When the pressure is on and we need to get something done quickly to make someone happy or to keep our job, we cut corners and cross our fingers.

The truth is, no matter what your commitment to quality as an individual or an organization may be, you are going to have technical debt just as surely as you are going to have financial debt. The question is, how are you going to handle that debt?

Dealing with Your Technical Debt

First, don’t ignore it. The worst thing you can do with financial debt is to ignore it, just keep making the minimum payments month after month, and pretending there’s no problem. Just as you’ll end up paying more (probably much more) in the end financially, technical debt that is ignored is the gift that keeps on giving. The problems it causes, the workarounds you have to do, etc. all just keep on coming back. You must recognize that you have debt, recognize that although you may have done it for a positive reason, keeping it around like Scabbers the rat is not a good idea. One of your goals IS (not ‘should be’) to eliminate it, hopefully sooner not later.

Second, triage your debt. If you have five credit cards, you’ll want to pay off the ones that will give you the most bang for your buck. Sometimes this can be based on the interest rate. Sometimes this can be based on the balance on the card. What you need is a way to quantify the cost of this debt on a monthly basis and then hit the big boys first. The same is true for technical debt; you have to find a way to put a value on it. Maybe you can monetize it, or maybe just assign it a nuisance value from 1 to 10. Then you can whittle away at the debt, either taking the big hassles first or maybe knocking off the little guys first so you can focus.

Third, and this is the most important in my mind, impose a debt ceiling and schedule regular time to work it off. Once you start incurring financial debt, it’s very easy to continue to pile on additional debt, and so people will often impose (or have it imposed) a maximum amount that they can borrow. Similarly, once you start creating technical debt, you need to find a way to limit how much of it you have.

Keeping a log of how much time and effort it would be required to eliminate the debt that you currently have can put things into perspective. At the same time, build debt-reduction time into your schedule. This does two things: it helps you find the time to reduce your debt, and it says to the company that eliminating technical debt (much of which was incurred because somebody wanted something fast) is a very real task and one that consumes resources that could otherwise be spent on developing new functionality. When others understand this, they may be less inclined to pressure you to incur debt in the future.

And in Conclusion…

We are all in some level of technical debt; you’re not going to avoid it. But you can live with it, and control it rather than it controlling you. See it, quantify it, and regularly work on it. Yeah, that’s the ticket!

Haven’t heard enough about technical debt? Here are a few more articles (there are a million) you might find interesting:

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Anonymous

    Great article.

  • Anonymous

    I’ve currently been working on adding new features to an application built by a web developer new to the job. The application is so difficult to work with because there have been some terrible short cuts which have been made. This article makes the point of why technical debt is important to manage and reduce. I liked the comparisons you made about looking at technical debt from a financial and quality point of view. Quality is important in software craftsmanship and technical debt appends time to maintenance and addition of new features.
    I would appreciate if you’d write another article that covers identifying code that is technical debt and prioritizing the reduction of technical debt.

  • George

    Another important aspect of technical debt is the effect it has on morale. If the hot-shot superstars continue to crank out prodigious but crappy code, the others are left fixing it and not getting their own work done. This makes them look bad if the bosses think that they don’t produce, and builds resentment. There’s no sense of team and people are less likely to share ideas. The employers are not getting the full value of a team and risk losing good people, thus lost production and time spent hiring replacements. A high turnover rate is never a good thing and word spreads in the community that this place is not a good work environment, that it is cliquey, or that it is a sweatshop. So the good people avoid the company and only those fresh out of school, who also think that cranking out code as fast as possible is the way to get noticed, take the jobs. Eventually, as the code becomes flakier, it affects the morale of everyone – the sales teams, the support staff, account managers – anyone who has to hear about all of the problems clients have with their products.

  • Matthew Setter

    Dave,

    Thanks for a very thought provoking article. As I read through it, I wondered how I could marry up an attitude I hold on financial debt, which is that if the debt brings in more than it costs, is it really bad, with an analogy in technical debt? I’m still pondering that one.

    It’s really helpful to make the comparison with financial debt, as it is very practical. The one thing I wonder though, is what is debt and what is “well, I could have written that so much more elegantly, in a more sophisticated manner”? I’m not completely conversant on the topic, so don’t want to go on. But thought it worth asking.

    Thanks again. Great article.