Stop technical debt from crushing coders!

Working on projects with a lot of technical debt can demoralise even the best coders. What is it, and how can we avoid it?

By
Box UK
• Apr 23rd, 2013

What is technical debt?

Technical debt is the term used for the consequences of not tidying up software as it’s built.

Generally the result of taking shortcuts – of bodging things “for now” – technical debt is a way of describing the accumulation of all the technical mistakes that have been made over time. We all have to take shortcuts sometimes but if these aren’t then addressed at some point they can become a huge problem later, as we will see.

Technical debt can usually be described in terms of antipatterns and can also be caused by design decisions; architecture that won’t scale, a database that is hard to search, and so forth.

What are the effects of technical debt?

If you’re a coder, you’ll already know the impact of technical debt. If you don’t code, I’ll try to draw a picture of it for you.

Imagine you’re a builder. You’ve been asked to build a new bathroom in a house. You have all the tools and parts, you’re ready to go, you can SEE the bathroom in your mind, but you don’t have as much time to do it as you think you need.

Now imagine that the house is built on loose, sandy soil. The walls are not firmly founded; they’re shored up with angled beams. The plumbing just leads to a pit in the ground. The roof doesn’t fully cover the house and the rain gets in. The electrics periodically cut out so there is a generator in the yard that backs it up. Every so often, a wall falls down and someone runs over and pushes it back up again and tapes it back on.

Everything inside you tells you to stop work on the bathroom and fix the foundations first of all.

But somebody is shouting at you to get the bathroom finished.

This is what working with technical debt can feel like.

You report that you need to stop working on features and fix the underlying problems but it falls on deaf ears, which hurts your sense of craftsmanship.

You feel like people think you’re a lousy builder who simply can’t build fast enough, which hurts your confidence.

It happens gradually, but eventually you can barely stand to come in to work in the morning.

A lot of good coders leave jobs at companies that don’t address the issue of technical debt. They can simply no longer bear working on projects that have achieved this kind of “critical mass”.

What can be done?

Existing in most projects to an extent, here are three distinct options to deal with technical debt, from least to most invasive.

Option 1: live with it

This is where technical debt is simply accepted as part of a system.

If it’s not too bad and the system is still workable you might be able to carry on, accepting that the system is, like most things in the world, not ideal. I’d go for this option if a system is in maintenance mode and no longer has new features developed for it – for example, a product that is feature-complete but that may still require occasional bugfixes and security patches.

Unless significant feature development is going into a product, it may not be worth trying to “fix” it.

Refactoring is improving the design of existing code without changing its functionality. Remember, we’re not necessarily talking about bugs here, but making the code easier to work with. This is the preferred option in most cases as it doesn’t throw things away. It is, however, time-consuming. Myself, I refactor as part of my Test Driven Development (TDD) workflow and I recommend that refactoring be done as you go along (like in a good kitchen where the utensils are cleaned as you go, so a massive pile of washing up doesn’t accrue).

For this to work, it is important that managers and product owners acknowledge that refactoring is a vital phase of coding.

Option 3: total rewrite

If a system isn’t designed well, it might actually be largely untestable and, you should NEVER REFACTOR WITHOUT TESTS!

If the architecture is bad, and the whole system is bad, then no amount of chipping away can rescue it. This is when a rewrite should be countenanced; only then should you effectively throw out functioning code.

This is the most invasive approach. From a commercial standpoint, it might not even be considered as an option. If that’s the case, though, the business runs a high risk of haemorrhaging developers for the reasons we discussed earlier. Sometimes, the plug has to be pulled on a system and failure to do so will only prolong the pain – you may sacrifice morale, opportunity cost and even your best engineers as a result.

Prevention

As with most things, prevention is better than cure. There are many technical and process-based measures that can be taken to reduce the risk of accumulating technical debt and, furthermore, refactoring should be part of any Test Driven Development work loop.

It’s not just a technical issue, however. Managers need to work with coders to understand what the extent and ramifications of technical debt are on each project. In turn, coders need to clearly and professionally communicate what debt is being accumulated and how to effectively triage it.

Taking on projects

When taking on a new project with existing code, it is vital that analysis be carried out to determine the level of technical debt already in place and create a plan to deal with it. Otherwise, you can end up lumbered with an unmaintainable mess!

Game over, man!

I hope that this post has given a useful insight into what coders go through when dealing with large amounts of technical debt. This debt can cause a business to miss opportunities, suffer from poor morale, and even lose staff. It’s not all doom and gloom though – learning about why technical debt has built up enables you to put appropriate measures in place to manage it.

To learn more about how you can uncover the levels of technical debt present in your systems, visit the Code Review section of our site, and email development@boxuk.com to request a product sheet with further details.

Box UK

Comments

Kevin

Apr 24th, 2013

Nice article on an important topic Gav. To add the prevention cause, implementing code reviews is another good measure to help prevent poor code going through.
It’s often best to have another pair of eyes look over the solution as sometimes you can become too focused on one aspect of the problem to see the wider picture of the whole application.
There are a few tools out there to help with code reviews, such as Atlassian Crucible (paid), Rietveld (free), or if working via Git, pull requests can form part of the review process.

Box UK

Apr 24th, 2013

Thanks Kevin, good point!
I’ve not used Crucible or Rietveid, but we are working with pull requests on most projects. It’s a great way of sharing knowledge as well as keeping code clean. It *can* descend into nit-picking, but 99% of the time is one of the best shields against accruing technical debt. If it wouldn’t get past your coders, should it go to your users?
We did try using code review plugins for Redmine with some success, but it was a bit bobbins compared to Github’s smooth integration.
Thanks for commenting!

Sebastian

Apr 24th, 2013

Excellent article.
I liked your analogy very much (being obvious that the foundations need work, but somebody shouting at you to finish the bathroom – brilliant).
And I’m also glad to know that I might have been mistaken in my perception (“You feel like [...] you’re a lousy builder who simply can’t build fast enough”).
Also very good and down to earth your suggestions on how to deal with it.
Kudos,
Sebastian

Box UK

Apr 24th, 2013

Hi Sebastian, thanks for your comments!
Many of us coders suffer from poor self image due to the pressures we work under. It’s actually pretty common for quite excellent programmers to think that they’re terrible!
Thanks,