Tackling Technical Debt

Most startups accrue a large amount of technical debt whilst they develop the first versions of their product. This isn't a problem. Many startups don't know exactly what they need to build until after they've shown something to their users - spending time perfecting these initial versions might be valuable time wasted.

This build-up of technical debt becomes a problem once the company reaches a certain size - often when the company knows what is needed and is more focussed on growing the customer base and scaling the software. This build-up of debt constantly slows down the technical team and reduces effectiveness. In some cases it can even bring development to a grinding halt. So, what do you do to reduce your technical debt?

Get your Debt Visible

Before you embark on reducing your debt it it is worth spending time helping everyone understand the problem. Your sales and marketing folks probably don't (yet) care about your refactoring needs, further, some on your technical team might not be as exposed to your debt as others. It's hard to justify spending time on a problem if not everybody agrees that there is a problem.

So, get your debt visible. You can use fancy solutions such as Geckoboard to allow everyone to see the impact in real-time. Alternatively, simply sending an email every day or week summarising the situation can work wonders.

But, what do you show? There are lots of ways to measure the cost of your technical debt and here's a few to get you thinking:

  • Code complexity
  • Test coverage
  • Time spent on support issues due to technical debt
  • Slowdowns in new development caused by working around existing problems
  • $ worth of transactions lost due to technical debt (e.g. a client walks away due to instability in your platform)

An easily understood measure that is close to the business is your strongest ally for getting your business behind your attempts to reduce technical debt.

Once your business understands that there is a problem it is usually worthwhile explaining how you've got this problem. It's not because you're cowboys, it's because you wanted to help the business get established quickly.

Paying off the Debt

How Much to Pay Off

It is tempting to spend a lot of time paying off all technical debt and making everything rock solid. This has a few drawbacks:

  • It's demoralising to spend a long time reworking old code
  • It's demoralising not creating new and exciting things
  • It's impossible - you'll always have something that you're not totally happy with

Instead, I find it works best to nibble away at technical debt a little bit at a time. E.g. have a week or two of codepocalypse and then get back to normal. If you've taken the time to decide on a measure for your debt then you can use this measure to decide how long and often these binges should last.

What to Pay Off

When faced with a lot of technical debt there is a tendency to favour the massive rewrite. Resist that urge.

The most important thing to do is to prioritise your debt. It's easy to send your team off to tackle their favourite bit of debt, but, that doesn't guarantee good results. I tend to prioritise these things:

  • Hard stuff. The hard stuff is rewarding and is unlikely to ever get fixed in normal day-to-day development
  • Infrastructure. Infrastructure, (e.g. server setup, error reporting, logging) is also likely to be put off to another day during normal development
  • Common moans. Optimise for happiness. If everybody groans when they have to work in a certain area then get that fixed

Useful Techniques

Delete and Simplify Functionality

Remember that reporting functionality written six months ago as a trial feature? Does anyone use it? No? Delete it. What about the ultra-granular analytics you provide? Simplify them if no-one uses the granularity.

Scan your entire product for functions no longer called and features no longer used. Deleted code incurs no debt.

The Debt Register

Tracking your technical debt in a register is a great way to help prioritise. It can also be useful for reducing technical debt. Just the act of registering a bit of technical debt down can be enough to spur someone into great efforts to reduce it - pride is a wonderful thing :)

A debt register is also helpful in planning normal development. If everyone knows where the debt is then you're less likely to get nasty surprises when starting work on new functionality.

Classify Your Code's Debt Appetite

Some code is peripheral and can have a high amount of debt before it becomes a real problem. Some code can't. Your layer for talking to your database should have a very small amount of technical debt. Your cron job that sends a daily summary of new customer counts can tolerate a fair amount of technical debt.

Take the time to identify the areas of your system that are not tolerant of debt. Make sure everyone knows what these areas are and why.

Got Money? Use it

When bootstrapping a startup there are always a few technical decisions that are driven by financial reasons, e.g. "let's use these hosts because they give us free credit". Sometimes these decisions incur a lot of technical debt and the debt can easily be paid off with the sprinkling of some cash. Evaluate your past decisions (easy if you have a technical debt register) and decide if any can be wiped out with a bit of money.

How to Reduce Further Growth

After paying off your debt further growth of technical debt is inevitable and is not necessarily a bad thing. If taking on technical debt allows your company to move faster on things it needs to then it is a debt worth taking. When taking on more debt remember to keep the company aware of this so that it is not taken by surprise later.

Many start-ups in their early phases produce code of a general lower quality than more mature companies where quality is of greater importance than speed. Shifting your start-up team into this mentality can be hard. Getting the debt visible is a big step towards changing this mindset. Encouraging the team to have a big discussion about how to produce better quality code can create a surprisingly rapid change due to the team being much more bought into the solutions that are thought of.

Conclusions

Technical debt is an inevitable result of any startup trying to move fast. The trick is to not get drowned by it.

Further Reading

Discussion

blog comments powered by Disqus

Colin Howe

I'm Colin. I like coding, ultimate frisbee and startups. I am VP of engineering at Conversocial