June 2016
Mon Tue Wed Thu Fri Sat Sun
« Apr   Jul »

Day June 20, 2016

Drowning in (Technical) Debt

If you deal with software, you deal with technical debt. I’m not just referring to people involved in creating software, I mean anyone using software. Technical debt is the result of compromise, sloppiness or lack of knowledge. It’s the enemy of any business, leading to wasted productivity and unhappy customers.

If technical debt is something you’re already well aware of, and you’re more interested in ways of getting rid of it, you might want to skip ahead. Plenty has been written about ways to avoid creating technical debt (refactoring, test-driven development etc.), but what I’m addressing in this post is more pedestrian and practical – how to you find the time to fix the technical debt you already have?

First coined by pioneering programmer Ward Cunningham, technical debt is perhaps most easily understood as what happens when a developer decides to (or far more commonly, is asked to) take a ‘fix it later’ approach to a known software issue. Of course, ‘later’ never comes, as new work comes in. The problems that technical debt causes typically aren’t visible to the people setting the business priorities – because they’re not the ones dealing with it.

But just like financial debt, companies pay interest on technical debt. Interest in the form of time spent; doing manual workarounds, rebooting servers or worse, security breaches and lost revenue as a result of downtime. And just like financial debt, the more technical debt you accumulate, the more your developer ‘budget’ is going towards interest payments at the expense of actual project work.

A brief aside – I’ve mentioned The Phoenix Project before. It’s a great book that does an excellent job of illustrating the impact of technical debt in a real-world context. If you’re having challenges getting buy-in from your IT management to pay down technical debt, I suggest you buy a few copies and pass them around.

Fine. Technical Debt is bad. So now what?

As mentioned, much has been written about avoiding technical debt, and hopefully your development teams are already adopting practices that minimize the amount of technical debt that gets onto production. But in my experience, the more common challenge iswhat to do with the technical debt you already have? 

Developers are usually the ones who carry the burden of technical debt, and are often the least empowered to advocate for fixing it. An hour here, 15 minutes there – over the course of a week or a month doesn’t seem like a lot, compared to two or 3 days to actually fixing the root cause. It’s hard to get buy-in to fix any one issue.

However when you end up with 10 or 20 little issues that individually take up an hour or two every week it becomes incredibly disruptive. Worst of all – these issues often appear sporadically and require immediate attention – aka unplanned work (another recurring theme from The Phoenix Project).

So how do you build a case for getting executive buy-in for fixing technical debt? As usual, the key is creating visibility.

If you use development software like Jira, Pivotal Tracker or Rally, you probably already have the tools and processes you’ll need. In the example below I’ve created two tickets in Jira. The first, TECHDEBT-221 is an ‘open ticket’ that I’ll use to log developer time whenever someone needs to go in and perform the workaround caused by a single broken application. Each time the task is repeated, it’s tracked in the work log at the bottom, and cumulative time spent on the workaround is easily visible on the right (to date, three and a half days).



Then, I create a second ticket (below), TECHDEBT-222, which is the permanent fix for the broken application that will eliminate the need for the manual workaround. So far I’ve logged about 90 minutes investigating the issue, identifying the solution and documenting the fix. Most importantly, the team has estimated the time required to complete the permanent fix to be about 2 days (yes I know it should be story points, I’m trying to keep it simple here).



So what does this tell us? When I created TECHDEBT-221 I created a way of capturing cumulative time spent on a task that I would need to do again and again. While it was fresh in my mind, I also created a ticket for the permanent fix, and then linked the two tickets together. Over time, the hours captured in the workaround ticket increases, and fairly quickly I’ll be able to forecast at which point the effort spent on the workaround is greater than the effort of the permanent fix. In the example above, I’ve already spent a day-and-a-half more in developer hours on the workaround than would be needed for the fix in the first place.

One more thing: If your organization can manage it, a very empowering exercise for your teams is to set aside a dedicated technical debt sprint. Ideally every few months, each team gets to choose the technical debt tickets that have been bothering them the most, and have a sprint dedicated to fixing them. If you’re having a hard time getting buy-in, try getting agreement to a technical debt sprint in August, when most businesses are at their slowest, or pick the last sprint of the calendar year when many shops go into code freeze before the holiday.

If you’ve done a good job of documenting how much time has been wasted on workarounds, and can compare to the time required to fix the underlying problem you should be well positioned to identify the most ‘expensive’ technical debt – and most cost-effective fixes – in your codebase.

– thanks to Matt Drewitt and Brad Botting for the 3 minute hallway conversation that formed this idea!

Additional Links: Interview with Gene Kim, co-author of The Phoenix Project

– posted June 20, 2016