Visualizing Software Technical Debt for Managers

Software is a hard field. Writing code in a good enough quality and maintaining it over a longer period of time is mentally consuming, especially after new features are coming in at a constant pace. The architecture starts to suffer. It deteriorates slowly if we don't take actions against it. It is the universal law of increasing chaos if we don't invest an significant amount of energy to fight it.

In software people call this phenomenon tech debt. It's like when you take a credit at a bank: you get the money (ship feature) at the same time you get the burden of interests (architectural disorder).

What's especially bad with tech debt is that you don't see it directly. There is no account which highlights "47 points of tech debt accumulated". Developers tend to have a gut feeling about it–most often they complain about that there's too much tech debt. When you ask the developers where the problem lies then you get basically this answer: "Everywhere!".

This response usually doesn't help and we still don't know where to start reducing the tech debt for the best return on investment. Bigger companies work with a lot of management KPIs so why there isn't one for tech debt? This would give managers and developers alike another helpful tool in their toolbox.

In the last decade I have spent a couple of thoughts on how great it would be if we had, at least, an indicator where to look at. Something that points you at the biggest mountain of garbage of all mountains of garbage. Over the years I've developed my own technique on how to find such hot spots in the code. When joining a bigger code base–let's say 100k+ lines of code–what I did was the following:

It gives me good hints on what places in the code could turn out to be hard to change, evolve and maintain. I didn't use a tool for this metrics so it's unpleasant to repeat over and over. I did it mostly "by hand" with ad-hoc scripts using an IDE and the command line. It was better than nothing but suffered from just being a snapshot in time. It lacked the time factor.

Lately I stumbled across the activities in this field from Adam Tornhill. He also wrote a book about how to do forensic code analysis which should serve as a tool to pinpoint problems in a code base. I read it. He describes all the techniques in sufficient detail so that you could implement them yourself. His approach is similar to the steps that I do but also includes the time factor which I left out.

Adam looks at the project's code history by extracting this information out of the source control tool like Git. The premise is that complex code doesn't necessarily pose a problem. In contrast it does so when it is touched and changed. The more frequently it changes the worse it gets. It's so simple and clever at the same time that I cannot believe it didn't come to my mind–I'm not feeling envious.

Currently I'm using Adam's approach for a consulting project. The scripts (they are free and open-source) are ready-to-use and help to inspect the project's code and architectural health. The company faces some big challenges because they want to get away from a project-specific to a more product-oriented offering. It isn't an easy job but this tool gives me–as a consultant–but also the company's management an additional tool to detect defects more easily than just solely relying on gut feeling.

Back