The economy of tech debt

Most articles about tech debt are pretty much theory only with lots of interesting philosophies. I’d like to approach this topic in two steps:

What’s Tech Debt

Tech Debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

It was introduced by Ward Cunningham with the following words:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid.”

So, in fact:

What’s Not Tech Debt

It is often much easier to put all the mess under the tech debt umbrella, but there is some stuff that is not eligible as tech debt, like:

Measure It

Before you consider any action, you need to measure it: a good metric to evaluate tech debt and plan any action is the amount of unplanned work.

Not all of the technical debt is worth repaying Usually when the time spent refactoring exceed the benefits it’s probably a better idea to just ignore the debt (note: you should still keep the track of it, where it lays and why you have decided to not address).

Unplanned work is any task due to bugs, service interruptions, or flawed software designs.
Statistically has been shown that unplanned work should represent from 5% to 15% of the work of an organization.
When it goes higher, it should be accurately monitored in order to avoid further problems.

Root Causes

Unplanned work, and therefore tech debt, have 3 different root causes:

Mounting tech debt means spread of unmanaged complexity, resulting in less business value being unlocked.

Simpler tasks require unnecessary cognitive load, which means more [shitty] work to get done and longer delivery times. Moreover, the result is anything but good, and the situation is going to get worse once new debts are going to be added.

Impacts are on the tech side:

… but also for the team:

Learn how to Communicate, Manage & Minimize the Impacts of tech debt in your code.

Communicate Effectively

Discussing tech debt with nontech people may be hard.

The secret here is to speak the language of business: Persuade your stakeholders that time improving the product behind the scenes will increase productivity, sustainability, and scalability.

Make the waste visible

The difference between financial debt and technical debt is visibility. It’s not always clear how much technical debt you have at any time. A tech debt follows 3 different stages:

As tech team, you’re like gardeners managing a green park along each season of the year. It’s springtime: you enthusiastically spend a large sum at the garden center and work your soil adding new plants (features) and architecting each garden (organizing your infrastructure).

Discipline is a fundamental part of your work.

You must be diligent, regularly tame and tends their urban oasis, ripping out weeds, and ultimately end up with a beautiful park (congrats, you are managing tech debts!). Failing to do regular maintenance, you eventually end up with a mess of dead plants everywhere, a dense forest, and frustration.

The goal is to make the waste visible, then schedule a plan to fix them.

Like working in a garden, software needs time and resources to keep it sustainable and avoid long-term costs.

The biggest symptom of tech debt in an average software is a specific issue or issues correlated to each other (by technical dependency) with a moderate/high occurrence-rate.

Hands-On Approach

As with any good plan, it starts measuring the impact.
You can’t plan or prioritize anything without knowing its impact.
Can’t avoid it, your job is to monitor where it is easy to find.
Once you spot it, take a deep breath and avoid fixing it immediately.
Annotate it in your backlog along with a meaningful description or a grade.

Tracking tech debts has a similar lifecycle of any product activity. Start grading your debt on 4 levels with a values between 1 (light) to 5 (heavy).

Now put all issues in an ordered list with those total grades.
That’s your priority.

Allocate time in each cycle

In my team, we have reserved part of any sprint (2 weeks) for addressing tech debt. The amount of this time may vary depending on a lot of factors (how big the activity is, pressure to deliver other product-related features…), but you should consider a dedicated slot (~20%) for each iteration. If you can’t commit to a fixed amount of time for each iteration, use the end of a quarter as a suitable time to do this.

Beware Artificial Deadlines

Deadlines can be real or artificial. Most of the time, artificial deadlines are used to set boundaries for all people involved. However, the hidden cost of an artificial deadline is a tech debt: while you think you can address a debt just after the release, instead, you may end up using the time supporting early changes and defects found.

Minimize Impacts

I’m sure you land in this paragraph hoping for a simple and fast answer. At this time, you should have learned you can’t avoid Tech Debt completely. It’s an inevitable part of shipping a product.

But don’t be discouraged; it doesn’t mean you can’t take some actions to minimize it:

Key Takeaways

· leadership