One of the more complex things for a software engineering manager, in a company that is not primarily selling an engineering product, is explaining what this tech debt is. Even though once that is explained, laying out how to quantify it is still sometimes a close to impossible task. (Also not worth it 🙂 )
I have recently heard that not dealing with tech debt is like deciding to not clean up your bathroom for a time. Lets take 6 months for an example. This makes it easier to explain benefits. The benefit of cleaning here is not needing to go to your neighbour to use the bathroom.
The rest of the article should help you with measuring tech debt.
I am personally using one set of metrics and a few indicators to assess the size of the tech debt. Metrics are obviously DORA metrics. You can read more about them here on my blog. In short – if your DORA metrics don’t look perfect, you can be almost certain some tech debt is holding you back.
Though what to do if you don’t have them implemented yet? I am using a set of 5 questions as well.
- How much time your team / teams are spending on BAU? (term frequently misunderstood by accountants enveloped in OPEX vs CAPEX costs. My simple rule is – innovation also happens in BAU, not only in new and shiny features :))
If little – this should be a warning sign for you. Teams which only work on new features are the fastest to forget to clean up the bathroom regularly. It quickly leads to the next indicator. - Is you tech staff attrition spiking?
If it is – that bathroom cleanliness (tech debt) might be one of the most contributing factors. If there is something engineers hate for sure, it is waiting hours for builds, flaky tests, never optimizing what they built, or working weekends, because that new release DB migration will take 8h and can only be done on a Saturday. - How good is your product documentation?
It is a simple test. Only-feature-focused teams rarely produce good product documentation. Also rarely have processes in place on how to keep that documentation up to date. Documentation usually suffers first, because people think that now they understand. They cry after 6 months. After 12 months nobody remembers why a was built not b. After 18 months all you can say for sure is the last person who knew this was Mark … and he had left a week ago. - How much code is getting deleted in your team/teams?
Again a simple ask. Feature-driven projects have a tendency to create temporary solutions / scripts / tables / infrastructure. Even in well-driven projects, things get out of date / receive updates. You should always see code being deleted. If you only add – smells like tech debt (not clean bathroom). - (Last but not least) What do your engineers say?
In most organizations, teams run retros … or some kind of summary … or just plain rant on the 1:1’s. The more you hear about it, the worse the problem is. And don’t fool yourself – they are mostly right. They spend most of their day close to the code. They just know.
I’ve been fortunate my recent organizations understood the problems tech debt creates. Though even in a perfect scenario, you might buy a house, where the previous owner decided to do funny things on the floor rather than using proper bathroom equipment (to save time), then put tiling on it to mask the damage. Also lit these little perfumed candles all over the house, when you were visiting.
If you have inherited something like it, you will need to invest to fix it. It will be costly and painful.
On the good side though, there are no projects I have seen that can’t get to a stage in the modern world, where high speed and quality with low cost are possible (see DORA above). It just takes that initial investment of time to get there.
I am often asked if this means no new features work in the mean time. NO! It does not mean that. It just means prioritizing engineering work should be on par with new features. Your teams will know the answer which split of time feature / tech debt is the most reasonable. TRUST THEM.
That’s all for today. I hope you found some of these insights helpful.
The video for this week is:
PS. Unrelated – I just loved this quote from Adam’s website:
I consider Accelerate (that Gene co-authored with Dr. Nicole Forsgren and Jez Humble) to be the most important technical book over the past years. The reason is because the software industry is largely fuelled by hype, claims, and promises that are rarely supported by data. Accelerate was a fresh breeze with its solid research and, to the best of my knowledge, the first work that convincingly links technical practices to business outcomes. The Unicorn Project packages all those lessons from Accelerate — and more — into an accessible novel that manages to enrich the core message by providing context that further strengthens the business aspect.
http://adamtornhill.com/reviews/unicorn-project.html
Gustaw Fit 