If you’ve ever built a big software project you’re totally familiar with the idea of technical debt, but it’s unlikely that your clients are familiar with it. So lets figure out what it is, and what we can do about it.

What is Technical debt

Technical debt can also be caused by building a feature under a specific assumption, then later in the project we add new features that change the assumption. With our assumptions changed, we now have to work around that original code. We know the whole time that we can rewrite the original code, under our new working model and we will have code that’s easier to work with.

Time is also a factor in technical debt. Decide you just have to have a feature ‘by tomorrow’ then it’s more likely someone is going to have to take a shortcut to hit that deadline. Sometimes if you want a feature it’s better to move the time requirement so that it’s right the first time.

Undoubtedly, as suggested by this article in 24 Ways, a lot of technical debt can be dealt with by better planning from the outset. Building under the model of Test Driven Development can also head off technical debt. Neither of these things mean that a project will have no technical debt, just that it’s managed better.

Dealing with Technical Debt

So how do we deal with technical debt? Well every 3 or 4 development cycles, we stop and evaluate the code based on our current working model. Then we refactor the code to suit the new model.

Yup that’s it. All we need is some time to deal with it. Maybe even an outside set of eyes to look at the code. Developers become blind to their issues, just like writers become blind to spelling mistakes and errors in their manuscripts.

The Client Problem

The issue is that it’s hard to convince clients to spend $$$$ to have us rebuild something that, at least from their eyes, works perfectly fine. Then we tell them at the end of the refactoring, it’s all still going to look the same to them. They often see no immediate return on investment for refactoring.

I’ve Left Projects

It will come as no surprise to the experienced developer to hear me say that I’ve left perfectly good clients because of technical debt. At some point the debt load becomes so high that the project isn’t fun to work on anymore.

The project has become an exercise in building ‘hacks’ to make the old models work still.

So Mr and Mrs Client, part of this is on you. When developers ask for time to refactor code, you need to give it to them. If you don’t you can be sure that they’re going to be less and lest interested in the project. At some point they’re going to leave and the next developer you hire is going to see a mess of code and declare it unworkable.

Your original developer knew it was becoming unworkable, that’s why they left.