Tech Debt Accounting

Technical debt is incurred whenever a sub-optimal solution to a problem is chosen because of some other pressure aside from technical merit.

Technical debt is only technical debt if you knowingly choose that sub-optimal solution, anything else should come under the heading of mistake, poor judgement or idiocy.

So if we knowingly incur this debt why don't we just always do the right thing, I would love to tell you that its possible to do that but the reality of working in commercial software development makes it difficult to truly put technical concerns before all others.

We Need to Ship

The reason we write software is to ship it and there are many more inputs into the decision on when or if to do that aside from the purely technical.

I would like to be able to give you advice to never allow your code base to be affected by these outside pressures but it just wanted be realistic.

Shipping software is important, it reenforces our link with our users and reassures them that we are working on ways to improve the product.

Its a fine line between making sure software is properly implemented and meeting a schedule of releases and because of this we will occasionally stray either side of it.

We may occasionally ship late and we may sometimes ship something we aren't 100% happy with it, if we accept this is the reality then we need a strategy for dealing with the consequences. 

Auditing Your Finances

So if we assume that at any time we are carrying a certain amount of debt how can we ensure that it is effectively managed.

The first step is to record it, the chances are all developers working on a code base know the areas that need work or that cause problems when dealing with change.

But this isn't enough, too often when developers talk about this stuff it doesn't register with others and this is mainly because they can't see the impact.

Instead have a central register of tech debt that briefly explains the nature of the debt and the impact it has. The next time in a planning meeting eyebrows are raised as to timescales or complexity being able to point at an entry in the register and explain this is why is invaluable.

Secondly every time a bug or performance issue is encountered that is either directly caused by tech debt or exacerbated by it assigning the developer time taken up in finding a resolution and the users affected will highlight that everyone is suffering from the debt.

Visualising the impact of the technical debt like this helps highlight to non-techies that there is value in this kind of maintenance and continual improvement, stability and performance can be a feature.

Now or Later

The biggest piece of education you can conduct around technical debt is that its currency is time.

Time saved by choosing the sub-optimal solution is always paid back in either longer timescales for new features or more time spent on irritating bugs or failures further down the line.

This doesn't always mean we are doomed to either ship later or spend time fixing our code base, we instead need to understand that tech debt cannot be ignored. That it isn't related to people not doing their jobs properly, instead we can all work together to ensure we instigate a cycle of shipping and optimising and shipping.

Stability and performance are often overlooked features but users do not forgive lapses in either of those two things for sake of a shiny new feature. Its not always easy but it is possible to establish a balance between the technical merit and the need to ship everybody just needs to be aware of the nature of debt.