Debt Management

We've all been in the position where we've been asked to cut a corner to hit a deadline, we don't want to do it but its part of the commercial reality of having to ship something out of the door.

Providing this is done in an Agile way by defining an MVP and leaving future enhancements for subsequent iterations this doesn't have to be a bad thing.

But every time we take an action that is sub-optimal we accrue a piece of technical debt, again this doesn't have to be disastrous but it does need to be properly managed.

Buy Now Pay Later

The first thing to realise about technical debt is that its effect isn't felt at the time its accrued, the pain comes when its time to pay it back.

The definition of technical debt is taking an action that is sub-optimal and will make future changes to a system harder to achieve, eventually this can build up to a point where no further change is possible, development grinds to a halt, and you can bet this will happen just in time for the next urgent release.

Very often a code base that is riddled with technical debt will be beyond saving, a re-write is the only cure.

For this reason its important to document technical debt both at the point its accrued and every time it impacts a future change. Quite often the sin isn't in accruing the technical debt its in letting it fester and not addressing it until its too late.

Be careful you don't buy a release with so much debt that your credit card is rejected when you next need to ship, instead be sure you have a payment plan.

Technical debt is like any other debt, your accruing interest all the time you haven't paid off the balance.

Credit Score

In an ideal world no technical debt would ever be accrued but the reality is you can't avoid it, but you can make sure you are responsible borrowers.

Martin Fowler describes technical debt as being a mixture of prudent/reckless, and deliberate/inadvertent, this gives rise to four possible groups who can accrue technical debt.

Reckless and Inadvertent = Bad Developers Just Doing It Wrong

This is less about technical debt and more about simply never having any hope of producing quality code, this team doesn't even realise there accruing technical debt and will undoubtedly end up insolvent.

They aren't cutting corners they are simply making bad design choices at every turn, there is no excuse for being in this group.

Reckless and Deliberate = Hacking It Up

This group might know how to do things properly but are happy to just "get it working". They don't appreciate the benefits of a good design and don't write code that is built to cope with change.

The first few releases will be fine but soon the stack of hacks will come crashing down with a wave of defects.

To not end up in this group you simply need to realise that your code working is the minimum requirement not the point at which you say "job done". 

Prudent and Inadvertent = Not Fully Understanding The Problem

This kind of debt is very difficult to avoid especially on a new project. This is what Agile is trying to teach us that anticipating and meeting the demands of users is difficult, that's why we ship early, fail fast and iterate.

The most important aspect of this kind of debt is to anticipate that you are probably accruing it and be sure to recognise early when certain design choices are causing issues and start thinking about a plan to make changes and pay the debt back.

Prudent and Deliberate = Being Realistic

This is the team that's on top of their game, they understand the system they are trying to build and they are realists who know that at some point you have to ship something. They fully understand which decisions are causing the debt to be accrued and they have an appreciation for the likely consequences and may even have some idea what the resolution will look like.

Don't be too hard on yourself if your not in this group, they are probably experienced developers working on a mature product.

Forewarned is forearmed, understanding the concept of technical debt and its consequences is half the battle, monitoring your debt levels and acting early to avoid bankruptcy will see that you can continually ship software and continue to iterate and add value for the user.  

Try and make the debt work in your favour by using it to buy the time to make the release but paying it off before the interest payments cripple you.