Technical debt is a term coined by Ward Cunningham in 1992 to describe the software engineering phenomena of how expedient, short-term decisions can have negative, long term consequences that make it difficult to maintain and update the software. The concept does not just apply to technology companies, any company that uses technology also has technical debt and understanding the concept will help you manage it and run your business.
What is Technical Debt?
Businesses accrue technical debt whether they are conscious of it or not. The results of technical debt are typically inefficiencies, and in software products, bugs.
The best-run businesses manage technical debt choosing to take it on while planning to pay it off. Their levels of debt fluctuate in a saw-tooth pattern as they set aside time to manage the most expensive and damaging debt.
Poorly run businesses don’t manage technical debt and keep taking it on until it grows out of control. Just like the costs of servicing interest can completely consume revenue if left to grow out of control, so too can the costs of technical debt completely consume the productive time of your employees and co-workers. When you see a software product and wonder why they can’t do something that seems simple, often it is technical debt that is holding them back.
Software Architecture Example
One good example of technical debt that illustrates some of the problems surrounding it is software architecture. A well-architected piece of software is easy to maintain while a poorly-architected one is a nightmare.
However, spending weeks at the beginning of a software project planning the architecture is all time that delays product launch. The problem is further compounded by the difficulty in communicating the importance of good architecture to business managers. Delays, on the other hand, are understood all too well.
Usually the best solution lies somewhere in between perfect architecture and rapid time to market.
The decision to take on technical debt is never a simple one. Software architecture is just one of many decisions that defer costs to a later date. If expediency always wins out and no effort is made to pay off the debt by improving the architecture, then a software product will become unwieldy. Simple modifications will break things in seemingly unrelated areas of the product.
Expanding the Metaphor to Business
You don’t have to be a technology company to have technical debt. Your accounting system, whether it is Microsoft Excel, an accounting suite, or a full-blown ERP system, is a source of technical debt. You make short-term compromises doing accounting on the inexpensive tools at hand until your business evolves to the point where your processes become too unwieldy to properly manage the business.
This is why technical debt is such a good metaphor. Taking on this debt can be a good thing. Used wisely it lets you grow faster than you could have without this debt. But at some point you have to pay off that debt. Letting it accrue infinitely is not an option and that is when you are ready for a comprehensively architected ERP system.
It is important to have a plan in place to identify when to move forward with an investment, and the types of considerations you will make at that point. We will explore developing that plan in subsequent blog posts.
