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:
David ShireyDave Shirey is owner of Shirey Consulting Services which provides business and technical project management, EDI set up and support, and various technical services for the mainframe, midrange, and desktop worlds. In addition to PHP Master, he also writes frequently for MC Press and Pro Developer (formerly System iNews). In his free time, he tends to worry vaguely about the future and wonder obsessively how different his life might have been if he had just finished working on that first novel when he got out of college.
