Driving Down Your StartUp's Technical Debt Before You ScaleUp
Published 00:00 on 13 May 2021
When I first heard the expression technical debt I thought it was a brilliant concept and I still do! Its about the level of sub-optimality thats buried in your system. It occurs for a variety of reasons including a lack of skill, a lack of time, or poor design. There can also be an accumulation over time. Maintenance work to use the latest versions of third party components on which your software relies, doesnt get done.
The concept is not solely limited to the code itself. It can relate to documentation too, where the written-down detail isnt very good. You might be relying on whats in peoples heads or worse, simply dont know. Whilst its a term primarily used in software, you can apply the same ideas to many technical systems and arguably beyond.
Technical debt is very context specific. A quickly assembled prototype that is only viewed through that lens can be as rough and ready as you like. Its not doing anything demanding and is there only to prove a point (as opposed to providing a live service). However, the same piece of code inside a passenger aircraft (extreme example, I know!) would instantly represent a significant element of technical debt. Its not the code itself thats problematic, its the fact that its a poor fit in the context in which it is being used. It will need to be improved at some point through what is known as re-factoring.
Technical debt in StartUps:
StartUps that are trying to scale are acutely vulnerable to technical debt. Early on new businesses are about keeping costs down and being good enough to deliver. As the business tries to scale, stability, resilience, low levels of down time and high levels of supportability all start to become more important. Youre not quite going from prototype to passenger aircraft territory, but youre significantly changing the context. The basis on which a system would be deemed fit for purpose is changing. This is the transition that ScaleUps are making.
As the name implies, technical debt is something that will probably need to be paid back. Before you get too far down the planning for your scale-up exercise, its well worth understanding how much technical debt youre carrying in the context of your planned-for scale. Your Dev Team will likely be very happy to explain it to you! You then have a choice about how much to fix and when.
So what do you do about it?
Id advocate doing what you reasonably can as soon as you can for two reasons. Firstly, technical debt is often an accident waiting happen. The accident can arise in various forms. It could relate to a security vulnerability which gets targeted. Equally, changes upstream or downstream of the system could suddenly expose it due to the speed or volume of transactions, say. It might equally be a personnel issue where someone leaves or is off sick and they were the only person who knew anything about the intricacies of it.
Secondly, technical debt, just like real debt, will eventually require cash and you wont get any forward progress at the time you pay it back. Youll simply have resolved an outstanding risk or issue. You need to think carefully about how much of your development time in the future youre comfortable to committing to resolving the problems of the past. It might well seem quite strange or even unacceptable to be spending money in year two, three or four dealing with things that were not done right in year one.
There is a need for pragmatism though. Clear design frameworks and coding standards will help a lot but its hard to drive tech debt out completely. This is partly because of the cost/benefit dimension. Each aspect of technical debt will have its own risk and impact profile. Dealing with absolutely everything is probably not viable or worthwhile.
Also, whilst in theory the volume of new technical debt created in a better managed larger scale enterprise will be less, it probably wont be zero. There will always be time imperatives or bits of code that end up becoming more pivotal than they were originally envisaged to be.
To conclude, technical debt is worth understanding and tracking. Dont let it build up to the point that its causing routine issues. Get a strategy in place to drive it down. If youre planning significant growth in terms of platform usage or users, deal with the worst of the debt first. Its also worth having a regular budget or sprint allowance for dealing with it. The situation you absolutely want to avoid is a huge heap of refactoring that is needed simply to stand still just at the point when youre trying to deliver real growth!
Simon Brand is the Founder of Enhancico Limited. www.enhancico.com
Last updated 16:57 on 13 May 2021