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 OnStartups.com was started.