Dealing with tech debt

What it is

Technical debt is a set of decisions that were made in the past, that you want to change now. These decisions can be related to architecture, software design, infrastructure or even some of the code you wrote. Some of it was deliberate: you needed something out of the door and accepted the consequences, meaning to come back. Some of it was not, because nobody on the team had worked in that area before.

It compounds. Change cycles get longer, individual changes get harder, and parts of the codebase turn fragile. You can watch it happen in the estimates: the same size of work costs more every quarter, and fewer tickets clear in a sprint than did a year ago.

How to pay it down

There are two different ways to pay off technical debt:

1. As part of regular roadmap work

For example, when working on the MVP of the Order Management System we've decided to cut some corners. As soon as you plan to work on tech debt items you incorporate this work as part of the upcoming areas or milestones of work. But then come back later when doing the next chunk of work related to this area.

2. As a separate initiative

For example, if you see there's an area of the code that developers are trying to avoid touching or afraid to change at all - to me that's a big red sign of tech debt. However, even if there's no item on the roadmap associated with that area it may still be well worth the investment to improve that piece. So that it's easy to make the change when you need it. And you don't have developers that are afraid to touch it.

Either way the items belong in the backlog, reviewed and prioritized like any other ticket, with the dev team's input on what to size them at.

The thing to keep control of is the rate. Debt you chose, logged and scheduled is a financing decision. Debt that accumulates unrecorded is the one that eventually sets your release dates for you.