Technical Debt for Investors

The potential returns of investing in or acquiring startups can be phenomenal. The problem is that pretty much every business worth investing in has some kind of software at its core giving it the competitive edge. Why is that a problem? Any bespoke software has debt associated with it: technical debt.

Technical debt is a concept in software engineering; there is a cost to short-term decisions, inexperienced decisions, or having a lack of clarity. This cost converts to debt, and it is accrued within the code, which is why its called technical debt.

Interest on the debt appears in the form of architectural rework that needs to be applied across the code, generally costing more than doing ‘right’ the first time. With software, its bloody hard to know what ‘right’ is, so the best you can do is watch some measure of debt accrual.

The reality is that technical debt is often a business decision that looks like an engineering design decision, so the wrong people make it, or the right people make it with the wrong frame of reference.

We need to accept that clarity will emerge through iterations of development of software. The problem with iterations is that we may need different plumbing or foundations to accommodate the emerging understanding of ‘scope’. This is also assuming that the technology team have a perfect understanding of the scope. The reality is that lack of clarity in understanding the ‘problem domain’ drives disparity in what is implemented to what should have been. Each one of these ‘iterations’ is the accrual of technical debt.

You might also like The Dealmaker’s Guide To Tech Risk
Four questions that reveal insights into any software business that mitigate your risk.

Ignoring the need to fix the underlying code foundations for the sake of short term feature delivery is like all short term decisions: fantastic until it’s not. The problem is the illusion of forward progress for executive leadership is that unless that illusion is a result of an informed decision, forward planning is based on the illusion rather than the reality of an accruing debt.

As an investor, the illusion of a particular velocity in early stage of developing bespoke software needs to be tempered as the understanding of the problem domain is dynamic and shifting. The problem is not specific to startups, where mid sized enterprises are under pressure to show progress to executive leadership for the purpose of a merger or acquisition the same issues emerge.

Its important to understand that accrual of debt is not inherently bad. It is in fact essential for progress. The key is tracking and repayment of debt should be recognised as an important part of the development process and scheduled at regular intervals. The impact of debt accrual should be discussed with executive leadership and executive leadership need to be informed of the impact of the debt.

Deferred decisions are often due to delivery pressure. If you know you can rework it later, why do it now unless its absolutely necessary? Right? Maybe. Deferred or inexperienced technical decisions are another place technical debt accrues quickly.

In less sophisticated environments, the specialist nature of technical problems can be ignored. It is not uncommon to have developers that are literally learning on the job. Seemingly simple pieces of work that accrue a stunning debt later.

I remember a mobile application we were asked to investigate because new features were taking longer and longer to add – and for every change there would be a cascade of bugs to follow. Once we had a chance to look at the source code we were able to see the problem. The lead developer taught himself how to write a mobile app using this project – and what we found was a single 5000 line text file with no comments and no structure. Spectacular fun for any developer to maintain I’m sure.

This may seem like an extreme example, but it happens all the time. Some new technology comes out and becomes the buzzword and developers get excited – examples include; artificial intelligence, encryption, parallel computing, scalability, and micro services. Inexperienced technical decisions can come from some of the most experienced (and optimistic) technical talent through following technical trends without understanding their bigger impact.

The biggest problem with inexperienced or poor technical decisions is (ironically) not the fact that they are inexperienced or poor. It’s that they are often hidden inside the normal accrual of technical debt as part of the development process. Repayments on these kinds of debt can be huge – sometimes a complete rewrite. Using our debt metaphor, this is less of a bank, and more of a Vinnie the Loan Shark level of interest.

Finally, one of the most perilous deferred technical decisions that will incur the greatest debt (as such it deserves its own category!) is deferred or incomplete testing. Research found 30% of developers say that they don’t have time to test. As annoying as it is to ‘slow down’ developing features for the sake of covering a good chunk of your code with tests, the trade off is an army of manual testers going through the application every time there is a change.

Do the team start to brace themselves for the bug reports every time there is a release? That’s no way to live, but a good number of startups and established companies do this every day.

There are so many good reasons to avoid performing robust testing on a rapidly changing code base, it can feel like such a waste. This decision always comes back to haunt the team who generally have no idea how they are going to repay that debt. More than once have I seen teams drag development work out for months to catch up on testing to try and address ‘regression’ issues.

What is regression? “We didn’t touch that part” – yet somehow the latest updates broke it. How did the development team not know? No automated tests.

The reactive way to compensate for this is to perform extensive manual tests. Releases get less frequent. Costs keep going up with fewer and fewer features making it to production. It’s a software development death spiral.

So, as an investor or external deal maker, how are you supposed to know what technical debt lurks under the covers of the business? How on earth can you understand what you need to ‘repay’ before you take a bath in red ink and spend the next six months trying to figure out how to get the hell out?

Look for the symptoms of these issues and you might have some clues:
– Inability of the software to scale to meet growing demand
– Brittle system that has excessive bugs every time new features are added
– Growing time estimates to resolve issues and add new features
– Slower and slower release frequency of the software to end-users

The problem with developing software is its greatest strength; it can be easily changed and reworked after it is ‘done’. It’s like having the foundations of a building made of Play Doh! Even after the whole this is done, you can go back and move things around as much as you like. Without the right processes, skills, and reporting in place the whole building can unexpectedly fall down by adding a new ‘feature’.

Add to this the fact that technologies that software developers rely upon today are so complex, many do not entirely understand how the systems they use every day actually work. They are in a cycle of needing to constantly learn while being on the job.

Ultimately, technical debt is a result of the inherent conflict of balancing speed to market, a finite budget, and the need to achieve a scalable solution once success is found.

The best you can do is be aware of the need to measure and report on your technical debt and account for that in the decision making or due diligence process.

You might also like The Dealmaker’s Guide To Tech Risk
Four questions that reveal insights into any software business that mitigate your risk.

Leave a Reply


Your email address will not be published. Required fields are marked *