For those of you not familiar with the term “Technical Debt” – this is a concept introduced by Ward Cunningham (who is an American software Developer & a co-author of the Manifesto for Agile Software Development.

This can be summarised as: the incremental cost and loss of agility to a company as a result of prior decisions that were made to save time or money when implementing new systems or maintaining existing ones.

Financial debt is a term that most people are well versed in, yet technical debt can have similarly crippling consequences due to the hidden costs that it can incur.

Just like Financial Debt - Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit. The point is that the debt yields value sooner, but needs to be paid off as soon as possible.

So, how are we going to deal with our Technical Debt ?

So, I've split this into Management & Prevention

First step is to figure out what and how much technical debt we have

Just like financial debt, that has a seniority of what gets paid back first. Technical debt has a similar pattern of seniority; to begin with, we must start with our mission-critical systems. What technical debt do they have? Then look at the wider ecosystem—better put, what technical debt between your systems is causing us expense?

Keep this simple! - Get our top ten ideas and put them into a 2x2 matrix: easy/hard to pay down on one axis and degree of benefits on the other.

2. Next, we need to decide what to do

Once we know what technical debt we have, we now need to decide how to deal with it. There are many options to take.

It may ultimately be best to do nothing. For debt that is either assessed to be “small” or with a “low interest rate,” it may be optimal to just leave it—likewise, if there is significant “prepayment penalty” of paying it off early.
There could also be strategic advantages too. Being one version behind and staying there is usually fine and sometimes has the advantage of letting kinks get worked out on someone else’s money.

Paying back or reducing technical debt will involve replacing systems and taking the cost hit. This can either be done immediately, or over time through a process of gradual improvements. As with financial debt, there are creative ways in which you can “refinance” technical debt, with outsourcing the maintenance being one such way.

A good example is cloud-based software and hardware services – This brings in a comparison to the popularity of lease-based finance. Using cloud services is also an effective tool for reducing technical debt, both in removing CAPEX requirements and shifting the development focus onto the cloud provider.

3. Next, we need to create a payment plan

The main thing to remember here is to not get overwhelmed by the cost of reducing our technical debt and don’t try to pay it off all at once. This would be an ambitious exercise that could overwhelm an organization of any size or balance sheet.

Again, going back to the financial comparisons, we need to have a mentality of paying off the credit card with the highest interest rate first. This simply means attacking high value/low effort activities first.

Managing Technical Debt Going Forward

Once we’ve established our baseline and plan of attack, we are going to want to both preserve that visibility and prevent new debt from creeping in. Think of the exercise as a fresh start and a chance to implement best practices to prevent issues from ever escalating again in the future.

1. Establish best practices in coding and documentation, peer reviews, automated testing etc. Automate processes to perform regression tests / source code analysis. Leverage off the shelf tools like GitHub and SonarQube.

2. Use tracking tools to collect metrics –i.e. defect rate, time spent to refactor, and feature development over time, all of which will drive prioritization decisions.

3. Re-Train Our Underwriters - In simple terms, change management’s job is to ensure that new changes to the company’s technology system don’t impact other systems. They do this by ensuring that the new system complies with standardized methods and procedures. We should be using this process to prevent new debt from being introduced (or at least identify it) – Architecture Review Board to be stood up etc.

Hope this overview of how we plan to tackle technical debt will help you in your journey as an Engineering Manager / Developer 😇

Important 😸

I regularly post useful content related to Azure, DevOps and Engineering on Twitter. You should consider following me on Twitter