How to handle Technical debt? pt2
In part 1 I suggested that the umbrella term ‘technical drag’ be broken down, to better reflect where it came from, and therefore how it was created, into 3 categories:
a. Product debt
b. Technical debt
c. Technical maintenance
After getting feedback, I’ve changed my mind. I am agile after all (please notice the small ‘a’). Why? Several people high-fived me inside IMs with regards to my desire to categorise debt by what effectively caused it. They liked the idea of being able to blame someone… woah! Don’t do that! That’s awful and leads to the kind of culture illustrated by that swamp the hobbits scuttled across on their way through Mordor.
I get that my previous article on tech debt could encourage the wrong behaviours in cultures that aren’t quite so aligned as that of River Island’s, towards a shared goal, with shared values, etc. Apologies. I literally make this stuff up as I go along.
Drag not debt
For anyone working in an environment that doesn’t promote safety (only within such an environment is the space to be a rock star btw) I’m going to change my message. Rather than effectively ‘name the source of the debt’, try these categorisations instead:
- Old code
- Suboptimal code
- Suboptimal solution
Also, as it’s 2022 and everyone’s getting creative with words I’m calling technical debt ‘technical drag’.
How to address ‘technical drag’.
Yes ‘debt’ kind of works because debts need managing, they compound, etc but again it’s too easy to infer blame from that word. It’s most often considered to be a negative thing, and nobody wants to be associated with negative things.
The term ‘technical drag’ better describes the other side of the conversation anyway: ‘drag’ isn’t anyone’s fault, it’s a consequence of reality. It affords a better visual of a team moving slower as a result of working with ever increasing amounts of drag. Illustrative words such as ‘friction’ and ‘heat’ can be used to explain how such drag impacts stakeholder and indeed inter-engineer relations:
“It’s going to take HOW long??” == unwanted heat/friction.
The cost of doing business
The Second Law of Thermodynamics states that processes involving the transference or conversion of heat energy are irreversible, and that everything naturally degenerates into disorder.
Drag == friction == disorder.
Old code
Friction… heat… car engines! Cars wear out without continuous maintenance (tyres, oil, batteries, spark plugs, brake pads, etc). Just as a battery loses efficiency over time, code written years ago becomes inefficient due to updates, new methods now being available, libraries. It’s nobody’s fault. It’s rust. It’s physics. It’s ‘old code’.
Suboptimal code
Hey, we’re all human. We’re all under stress to deliver. Sometimes something that later makes one wince goes into production. Identify it with a comment so nobody judges you or wastes time trying to understand how something so awful can exist in the codebase, make a Jira ticket to handle it, and one day handle your ‘suboptimal code’.
Suboptimal solutions
The general strategies and approaches that worked well at one time become outdated. Business processes change so much that rather than keep fudging a solution into general alignment with one’s desired outcomes it’s eventually better to care about the longterm, identify ‘suboptimal solutions’, and handle them.
Why do some companies not accept reality?
In my experience, it’s when decision makers either don’t understand reality or they’re playing a short game for some reason (balancing a budget, impending retirement, lack of resource versus an abundance of more valuable ideas). Assuming it’s a matter of understanding, and therefore communication, let me arm you with ways to explain technical drag to your colleagues:
The difference between coding in a clean estate and coding in an old estate can be likened to putting box fresh fairy lights onto a Christmas tree, versus wrestling a mayhem of half broken lights down from your loft and onto a tree that is home to an aggrieved squirrel
It makes us start to believe the recruiters’ lies of amazing greener grass roles, where the beer tastes like Bitcoins and the bean bags have cup holders.
Ways to explain the pain to a corporate audience:
- If we unburden ourselves from N story points’ worth of the drag now, we’ll increase velocity by n% and handle x% less incidents
- We’ll put out N% less bugs, and be able to fix any bugs we do put out n% faster
- With every story point of drag removed, there’ll be a correlated reduction in friction between team members, teams, stakeholders and managers, which will obviously equate to higher engagement, velocity and value
It very much depends upon what whom values, and understands because anyone sensible will know that the data behind that second point had to have been plucked from a random number generator.
Time to measure a thing!
There are many ways to attempt to measure/prioritise technical debt. Many people will go to war in support of the RICE Score method (Google it). What I prefer is monitoring the cost of technical drag as it’s created. Measuring as it’s created is a great metric for product health.
Cyclomatic complexity is (basically) the total number of possible paths through the entire codebase. Eg: if the code contains one if condition then the cyclomatic complexity is 2 because there are two paths through the code (true and false). Simples? Simples.
This number increases with every piece of spiky code the team codes over/around. It decreases when such code is rewritten in such a way that reduces the possible paths through it. Let’s say an entire codebase has 2000 potential pathways through it, that’s your cyclomatic complexity right there: 2000.
Divide that value by your cost of development per hour (let’s call that £150) and you get a metric:
Tech Drag of codebase 1: 2,000 pathways / £150 = 13.3
Tech Drag of codebase 1 after some work: 2,500 pathways / £150 = 16.6
The higher the number (13.3 vs 16.6), the slower they’ll code in that area going forward, and the lower their efficiency will be. You can now express the cost of drag in that area of the code. Exactly how you express that cost is up to you. Until you start dressing it up and heralding it for more than it’s worth it’s just a trend line to monitor.
It’s worth the effort
Software engineering is cognitively heavy. Holding — and attempting to marry — abstract models and patterns in your head, with Amazon services you’ve not yet used, while managers like me shout words like “Metaverse!” in meetings is exhausting. Doing that with a weighted multiplier of ‘technical drag’ holding you back makes all that more exhausting.
The effort it takes to convince decision makers that it’s worth tackling technical drag is less exhausting.
