Technical Debt - The Ugly Underbelly of Buying a Software Business
March 27, 2019
by a professional in Charlotte, NC, USA
One of the greatest challenges in evaluating a software business, particularly one that has a number of years and a lot of miles behind it, is understanding where the bodies have been buried in the past.
Technical debt is the term that's been ascribed to having to pay for the sins of past product development. Unlike financial debt, however, technical debt is not usually a conscious decision. There is no moment where you say "I'm borrowing three days today in return for paying six days tomorrow." Furthermore, there's no clear way to calculate how much debt you've incurred and how long it will take to pay it off. It often accrues out of sight.
When you buy a software business, there is almost always trouble lurking. Even the most well-capitalized, well thought out products have issues that need to be fixed later. The business changes over time, people come and go, and it's easy to take shortcuts along the way.
In the next few posts, we'll explore the different kinds of technical debt, discuss how you as an incoming potential owner understand the amount of debt you're taking on, and finally how to think about paying the technical debt off.
As you search for and evaluate software businesses, fully understanding technical debt will help you prepare to face the challenges after you've acquired your company. Stay tuned!
from Stanford University in Portland, OR, USA
I think that I am noticing that even without technical debt, tech evolution is causing rewrites so fast that the special burden of technical debt is something I would consider less of a special cost. That is, if developers need to invest 30=40% of all their time refactoring anyway due to evolution, then it might not be a big deal that with big technical debt, that amount might be double.
My company has been working in Web development, simple php/mysql/javascript with different frameworks. The frameworks have changed. The big 7 tech companies are innovating so fast, they are setting expectations for users. It leaves the little guys forced to build on their services.
in Charlotte, NC, USA
I don't consider modernization of software as technical debt. That's a part of living in this world. Things change, so the key is to have architecture which allows you to insulate yourself as best you can.
Technical debt is generally a different category of "stuff to be addressed" than technology evolution.
The exception of course would be if you made poor choices to begin with. However, if you're rewriting every couple years there's something else going on in the organization. There's no good reason for that.