What is “Tech Debt”?
“Technical Debt”, or “Tech Debt” is a somewhat abstract concept to many of our investor friends that often needs a more concrete explanation. In this brief article, we cover what it is, why it matters in an investment, and a little bit about how to deal with it. We don’t get into the technical depths here but cover tech debt from the business/investment perspective.
Investors are all familiar with cash. And with businesses and cash often comes debt. Consider the phrase, “Pay me now, or pay me more later”? An example everyone can identify with: let’s say you purchase a brand new home entertainment system. On the outside, it looks like a $5000 purchase, but in the long run, it is going to cost you a lot more in interest if you do not pay off the debt as soon as the bill comes due.
In technology, debt works the same way. Technical debt comprises technical issues that should be fixed before they become larger and more significant like financial debt accrues interest. For example, a bug found now but not fixed until months later causes re-learning of the area of code where the bug lies with a large context switch for a developer, extending the time to diagnose and fix the defect adding cost to development. As another example, the decision to develop on or deploy an older technology (maybe because the team is familiar with it) may expose security issues and force a costly upgrade at a suboptimal time for the business. Common examples are older Visual FoxPro, Visual Basic, or Delphi codebases.
Is all Tech Debt bad?
Is all tech debt bad? No. Often small software businesses make conscious decisions to take on some technical debt given their present situation, just like a consumer often makes a conscious decision to take on some credit card debt. The hope is that the debt is paid back quickly. For example, a company may deploy a custom version of the software for one particular large client to secure a quick sale. The intention is that this is a temporary measure until the feature can be designed correctly for the wider audience. The business has every intention to come back to it. Just be careful, because “later” often equals “never”.
LATER = NEVER
How should Tech Debt be managed?
No software business is without technical debt. Effective ones closely track technical debt work items in the same way they track the functional roadmap and features. Keeping abreast of technical debt and paying it off sooner rather than later allows the team to innovate and not scramble at a critical time to replace a technology that is announced as no longer supported. This work needs to be merged into the backlog and addressed regularly before it becomes too burdensome or continually punted. Often this is a tough sell to the Product Manager or Product Owner who is focused on new customer functionality, but it is a necessary negotiation.
All too often the companies we evaluate do not maintain a backlog of tech debt and are not intentional in addressing it. There is a constant struggle to balance innovation and technical debt work. Having a formal technical and operational improvement roadmap is recommended to continued positive business success from the technology perspective.
Why does an investor care about Tech Debt?
Why does an investor care about technical debt? Because addressing technical debt adds cost and risk to the investment post-close, and may ultimately affect the valuation of the target company. For example, making a necessary move of replacing a codebase built on Visual Basic 6 which is no longer supported by Microsoft may cost the company millions of dollars (depending on the size of the codebase). Business risk of not addressing technical debt may include:
- Inability of legacy components to run on future operating systems
- Exposing critical security flaws by using technology that is no longer supported/patched
- Decreasing innovation efficiency due to a monolithic software architecture that is difficult to enhance
- Stifling learning for existing developers that want to grow their skillset
- Failing to recruit talented developers who do not want to work on legacy technologies
- Difficulty of supporting more modern toolsets that are built for newer technologies
- Bringing innovation to a standstill (we’ve seen companies that can no longer compile their legacy code!)
Don’t stick your head in the sand – having a complete tech debt list prior to investment is mandatory in evaluating any post-close costs and risks. If the target does not have a list, have your technical due diligence partner derive it as part of the due diligence process. Investors need a complete understanding of where the company took shortcuts and did not address them (Cyligent creates this list for you including urgency and cost to address). The future of your investment depends on it.