Most code bases have some kind of code debt associated with them, legacy code bases tend to have lots of code debt. The good news is, paying back that code debt isn’t a complete time sink – it has definite advantages too. Obviously, reducing code debt tends to make the team go faster, but it also tends to fix bugs.

Quite often where there is debt, there is not just a lack of maintainability but actual bugs that are frustrating your users. By cleaning up the code, you will often fix those bugs without any special effort to do so – it just happens because of the simplified design.

The other thing that I’m noticing about areas of code that have heavy debt, is that the debt is usually caused by a lack of understanding when the code was written. As such, by taking the time to clean up the code, you tend to learn how to work with that area and suddenly things that were impossible because fairly trivial.

As an example, the end of Swing text documents has some very unusual properties – the document is actually one character longer that it’s content claims. The last character is a magical new line that suffice it to say, “makes stuff work”. I have no idea why that last character isn’t reported, but it’s not. Since the last block element in the document actually ends on that character, if you want to remove that block element you need to do some fancy footwork, since you can’t remove the last character. We’ve seen various bug reports come in about people not being able to remove the last table, list, div or whatever at the end of the document for quite some time.  Today while paying back some code debt to clear the way for a new feature, I came across our nasty mess of work-arounds for the end of the document and took the time to clean up the code. The result is about a hundred lines shorter and should fix the vast majority of end of document problems, including a whole bunch we’re yet to discover. Paying back our code debt has made our editor better for users.

It’s really important though that you don’t just pay back code debt – you need to keep adding features to keep your product alive and sales going forward too. It’s not just a financial benefit though, if your engineers are spending all their time fixing the bad spots in your code, morale tends to go through the floor and you just stop caring. If you can mix in some debt repayments with interesting new features the team stays focussed and does better work. It’s a form of sustainable pace – what you work on is as important as how much you’re working.