Taking Control of Technical Debt

I just wanted to take a moment to write a very brief article regarding every developers *favourite* subject — Technical Debt. For anyone unfamiliar with the term, simply put its the cost of achieving a goal quickly without ‘doing it the proper way’. In a simple example, imagine you have a client which offers to pay for a new service, but they need it to be delivered quickly. You know that you could ‘hack’ together a solution that would do the job in a couple of days — but you’d like to do it a cleaner, better way, but it would take twice as long. In order to win the business, you’d probably agree to do it the quick way and clean it up later. This is debt is a technical sense, that you pay off by cleaning up the solution and ultimately doing it a way you’re happy with.

Technical Debt - Hacker Noon_Read writing about Technical Debt in Hacker Noon. how hackers start their afternoons._hackernoon.com

The concept is important and is fundamentally valid. The big problem is when it comes to paying it off the debt. Sometimes, finding a way to sell a business on the idea of spending valuable developer time to do a task, which can easily be seen as cleaning up or changing something which already works, can be very challenging. More often than not, the debt will continue to build up at a steady pace.

Part of the problem comes with not having a simple way to quantify the debt in monetary terms. If the office needs to buy a printer, you can make a clear business case. However asking for time to change something that only developers want to spend time on, which ultimately makes little or no difference to the end user, is hard to justify in terms of pounds and pence.

What’s worse, is when your team or business understand the concept of technical debt but have weak controls on it. Imagine that the company provided each developer with a credit card with no credit limit on it — quite rightfully, that would be an unacceptable business risk. So, that got me thinking, why don’t we have a Technical Debt credit limit?

What would a having a credit limit achieve?

Well, for starters it’s a way of telling the business that knowingly going into debt for the purposes mentioned previously is perfectly fine. But, it also acts as a reminder and prompt that when the level of debt gets too high, its time to start paying careful attention and invest time in paying off the debt.

So, why would the business want a credit limit?

Exactly the same reason they would want one on a credit card. Just like monetary terms, the inverse to technical debt is technical interest. This kind of interest has some very serious implications, which are often forgotten. The more interest you have to pay, the harder it is to pay off the debt.

Just like when a company has a crippling level of financial debt, the same applies to company which is reliant on their technology. Even more so, if their company is solely technology related. If technology is your core business, you should make sure you’re investing the time to make sure it’s the best it can be.

What are the risks with technical debt?

I’ll keep this brief as the risks have been outlined many times previously. But these are the big ones in my mind.

1. 
   

   **Ability to react quickly**Over time as your level of debt increases, it becomes harder and harder to introduce new features, services or general changes into your application without increasing the time spent during implementation, testing or bug fixing. Bugs are introduced more regularly as spaghetti code begins to exponentially increase complexity and you’ll find that even the simplest of changes take longer than they should.

2. 
   

   InnovationSimilar to the point above regarding change. You’ll find that your developers become more bogged down in the swamp of general day to day maintenance and the thrill of innovating and building cool stuff, which can be sold to customers, starts to dwindle. You’ll start to notice your teams velocity reduce as they are fighting fires.

3. 
   

   Developer happinessThe side affects of the two points above ultimately lead to your developers becoming demotivated, tired and sometimes resistant to change. Having your developers, who are the best advocates for your software, thinking its time to stop everything and spend months upon months rewriting it is a huge, bright sign that your technical debt is too high. This is when things can start to turn ugly through the frustration of your developers not being able to take pride in their work.

Going forward

Take the time to get together with your peers and calculate a realistic technical debt credit limit and start to begin sharing this with the business leaders and educating them as to why this is so important. Similarly, if you are the business leader — make sure your developers start to think about what the credit limit should be and take the responsibility to keep within your limit.

I’m by no means an expert in this field, but during a long traffic ridden commute it got me thinking about the idea of a credit limit being a good way to visualise it to business leaders. If you agree, feel free to share! If you want to continue this train of thought, i’m over on Twitter as @itsmattburgess.