Technical Debt is Risk Management

A few years ago I was lucky enough to work with Steve Freeman. Steve is the Gordon Ramsey of Software Development. If you have a badly formed code base, expect to hear about it. Steve worked with the graduate, Mark, on the team to “refactor”* some code. They created tests that clarified the intent of the code. Most impressive to me was that they reduced the size of the code base by 80%. Imagine you are editing a 200 page book with random duplication. Steve and Mark’s work reduced that to 40 pages and removed the unnecessary duplication. Everything was where it should be, and you only had to find something once rather than find a random number of instances. (Note: Some teams print off the code they delete and put it in a “book of dead code”) This was vital work as we were about to make significant changes to the code. The refactoring they did was pure risk management. It meant the chances of missing a necessary change were reduced as previously the code had been cut, paste and tweaked to death. Delivery risk ( endless looping in the test phase ) was reduced, and the risk of missing something in testing that damaged the production business was also reduced.

In Commitment we use the analogy of a kitchen to describe technical debt. A clean kitchen is one where things are in the place a professional chef (e.g. Gordon Ramsey) would expect them to be and it is stocked and ready to go. A kitchen where things are in the wrong place or the utensils and surfaces have not been cleaned and put away has technical debt as the chef needs to clean up and prepare the kitchen before they can start. The clean up and preparation is normally the first thing Gordon does when he visits a kitchen on one of his shows.

Each team will have a definition for good code. A definition of where things should be. Anything that does not conform to that standard is technical debt. Working on code that contains technical debt introduces significantly more risk than code without technical debt. The risks introduced include:

1. Delivery Risk. Technical Debt tends to blow up in the test phase where it cannot be managed, only responded to. The project Steve and I worked on was plagued by a team that did not have automated tests. The same bug resurfaced several times due to a lack of regression testing.

2. Business Case Risk. If the code contains technical debt, there is more likelihood that it will behave in an unpredictable manner and the changes will not deliver the value expected.

3. Risk to existing Model. If the code contains technical debt, there is more likelihood that it will fail in production in a way that damages the existing production system.

As such, from a risk management perspective it is often prudent to pay down technical debt before making changes. This is where Steve’s suggestion that the team regard the code base as a portfolio of sold call options is really useful. For each component of the system, the team can identify how much technical debt exists. The measure for the technical debt should be how much effort it will take to pay it down. This effort should consider how complex the debt is, and the staff liquidity matrix, namely how many team members can work on the component.

The product owner can then create a “tornado map” where they map out the high level road map for the next six months to a year. The further out, the more uncertainty there is. Using the tornado map, the product owner and team can work out which technical debt should be paid down now and which can be left. In some cases the technical debt may take a long time to fix, or contain too much complexity to estimate effectively. In those cases, it may be necessary to pay down the debt early. In other words, risky option positions should be closed down early.

Technical debt is much to do with the skills and perception of the team. One team may consider their code base to be clean whereas in reality it contains a lot of risk. As such, it is necessary to hire someone experienced at identifying dead code.

Like Gordon Ramsey, good developers don’t create so much technical debt in the first place, so it is cheaper to hire good developers in the first place so you do not need to pay for dead code. So my advice to you is to hire Steve Freeman, the Gordon Ramsey of code bases, for his sixth sense about code, someone who can say “I see dead code”.

* It was not a refactoring as there were no automated tests. Part of the process was putting the tests in place.

As suggested by Steve Smith, here is an example of what a Tornado Map would look like.

Although I apply this thinking, I have not created a map. This is the what the one in my head looks like that I use for this purpose.

The backlog is down the side with the Epics grouped into those expected to be done in the next month, quarter and year.

Across the top are the components of the system. I would expect them to be similar to those on the skills matrix for the team. The technical debt is displayed below each component. It is expressed in team weeks (i.e. SWAGs).

From the example, you can see the most immediate problems are the loader and especially the build system.

After the build and loader are sorted, the next problem is the blue component which will almost certainly be hit this quarter. The red component has less technical debt and might not even need to be changed.

Even though the yellow component contains a lot of technical debt, it is not going to be touched for over a quarter and is less important than the build system.