"The borrower is a slave to the lender" - Proverb

This is the second in a series of articles on technical debt, one of the biggest areas of risk for searchers buying a software business. The first article was an introduction to the topic, so if you're wondering what you've missed, the answer is not much! Just dive in here. We're focusing most of this series on the acquisition process. There's another set of obstacles once you're in charge and having to manage the team.

So...

What is Technical Debt?

Technical debt is either known or unknown incomplete (or poorly executed) work done in the past that must be fixed either now or in the future. Just as with financial debt, technical debt is getting something today in return for paying more for it tomorrow. The currency of technical debt is almost always time, which of course turns into money.

In the case of known technical debt, you make a (hopefully) conscious decision to defer doing something “the best way” or “the right way” in return for getting the work done sooner. I put those terms in quotes because we’ll revisit them later in this article.

In the case of unknown technical debt, you typically discover the issues as a part of ongoing work. It’s like someone took out a loan on your company but didn’t bother to tell you. It’s painful.

Regardless of whether it’s known or unknown, the longer you borrow your technical debt, the more it will cost you to pay it off.

What are the Different Kinds of Technical Debt?

Known Technical Debt

Taking on known technical debt is easy. It will come up in casual conversation or in diligence with the target's development team. They’ll say things like:

- “We SHOULD do it this way, but we do it this other way”

- “If I/we had more time, I/we’d probably do this differently”

- “We don’t really have time to automate X, so we do X manually"

- “We can push X off, but I think it’s a mistake”

- “That’s not the best way to do it, but if that’s what you want, that’s what we’ll do”

Any time you hear anything like the above, your antenna should go up. Why did they make the choice they made? Is there a pattern in the decision-making that hints at always taking shortcuts? Perhaps the business demands were irrational and this was the only path. Understanding how the team made decisions is a leading indicator of how much debt you can expect to uncover.

Now, notice I mentioned doing things “the best way” above. Anytime you hear this, you should push back on your developers. It’s common for developers to want to engineer something perfectly the first time because that’s how we’re wired. We like order. However, often times “the best way” is subjective and there’s an optimal solution somewhere between a hack and perfection.

Unknown Technical Debt

Unknown technical debt is the worst kind of debt. You have no idea it’s there, and when it surfaces it’s usually at the worst possible time. If the target hired people who didn’t know what they were doing, but were able to deliver something that works, unknown debt can go undiscovered for months and even years.

I also consider over-engineered and over-built solutions to be technical debt, because you will have to pay a second time to reduce complexity.

Unknown technical debt usually looks like this:

- While fixing one thing, two more things break unexpectedly. Welcome to software wackamole!

- Development tasks (features, etc.) take a lot longer than it should have to get done.

- The product feels bumpy and messy when you use it. Bad results almost always indicate flawed work

- There's no clear roadmap or strategy for how the company adds to the product. Lack of thought up front produces bad work down the road.

Obviously our list is not exhaustive, but hopefully you get a taste for how technical debt finds its way into a product. In our next post, we'll talk about how you uncover the existence of technical debt during evaluation and diligence. In our last post, we'll talk about how to think about paying it off once you're at the helm. Stay tuned!

Have questions or comments? Let us know in the Comments section or reach out to us directly.