If features are roads leading users to new experiences, then technical debt is the nasty pothole that one day will break their axle.
Developers dislike technical debt, it's the equivalent of running out of oil in your almost perfect machine.
Product owners dislike technical debt, it gets in the way of progress and new features that delight customers.
Customers dislike technical debt because they are product owners too and undeniably the most important.
The three types of users can be broadly categorised into two distinct groupings:
- The developers of your product where quality has a direct influence on workplace happiness and productivity.
- The consumers of your product, where quality matters most but they want speed when it comes to bugs and features. This faction includes both customers and product managers.
In this article I'll examine some of the key issues and areas to be aware of that I've run into both as a developer and a user!
The iceberg effect; issue may seem small on the outside but underneath the surface could have long term implications.
A small fix, a little change, a tiny little hack just to get it out the door. It's always tempting yet they are the little devil in your ear, whispering sweet promises of easy fixes and kicking the can down the road.
When you neglect technical debt or introduce that hack to get it working quickly you do the opposite of what we learn as we grow up, delayed gratification is key.
You can suddenly find yourself in serious trouble if you don't pay down your debt, don't let your system become the Titanic. Users of your system are like water, while a quick fix or workaround seems like a good idea to get one user on their way this route will inevitably become the dominant route for customers and support requests.
Debt should be managed, not eliminated
The iceberg effect and it's musings may send project managers into a cold sweat, no releases until we reach the developers' utopia? How can I stop this madness?!? The key here is to treat technical debt exactly as you'd treat monetary debt, it can be a good thing, allowing fuelled growth, ambitious plans and a multiplier effect. However we must manage it and not be managed by it, the minute the latter takes place is the moment we start the daily countdown until the iceberg.
Debt should be on a timer and it should be paid off at specific dates regardless of the impact. We're aiming for managed debt inflation over hyperinflation.
Revealing the true nature and danger of technical debt
This is a no win situation, it's very hard to show this in a clear practical way, either you pay it off or you eventually crash. If the former happens then you've delivered fixes and features slower, if the latter happens then you didn't speak up enough at the time.
Ideally reducing tech debt ought to go hand in hand with testing, I won't delve into integration vs unit testing but if you fix something then test it, if you can't then it's still debt you gotta pay off.
If we manage debt in a careful way then we need to purchase currency with product owners, we can acquire this via stable releases, minimum level of roll backs and as close to 0% regression issues. The better we manage this in tandem with the debt the more currency (leeway) we have to really add quality.
The ghost of back end data decisions is the same as having made erroneous marketing choices. If you wouldn't put out embarrassing prose to customers then you shouldn't be serving up results from embarrassing code.
Product can iterate, data in production means you are not working with a blank slate. Each change adds one new layer of abstraction that needs to be reworked, in a complex and well written system large scale changes are challenging but achievable. In a complex and debt heavy system large scale changes from a data perspective are challenging and are often the primary breeding ground of technical debt.
Knowing when to do the wrong thing
Muhammad Ali will forever be considered one of the greatest boxers of all time yet frequently he'd commit basic fundamental mistakes that would get a beginner scolded. He'd often cross his feet to allow himself to manoeuvre into an advantageous position even though the transitional phase was more perilous. We're not all Ali level in our disciplines, we should stick to the fundamentals 99.99% of the time yet sometimes doing the wrong thing can be advantageous in a transitional period.
- If you're going to be beaten to market and your cash balance is super low
- You have a serious bug impacting multiple users
- You've decided to pivot and are running out of time
- MVP or feature spikes
If you're in one of those four positions then feel free to do the wrong thing to get it working but I'd treat points 1-3 as the equivalent to having taken a technical debt loan out with an interest rate of 1000% and point four is where work should be thrown away post experiment (technical debt bankruptcy).
Alarm bells should be ringing if you take this approach more than a couple of times a year, ringing even louder if the task doesn't fit into one of the 4 categories above and practically ringing itself off the wall if junior or less experienced developers are taking this approach.
Experienced developers know the how and when to take technical shortcuts, juniors only with the how.
So you've made it this far and you're wondering where the answers are, the magic bullet, the framework that'll reduce tech debt.
They. don't. exist.
Instead I'd try to think of answers to the questions below each time you tackle a problem on your own or in a team;
- "Am I making this system better than it was before?"
- "Would I be embarrassed to show this code to someone I respect?"
- "How would I feel if my first task at a new job was working on this particular piece of code?"
If you've got positive answers to the above and your team mates agree then you're most likely on a more positive path than if you didn't consider these questions. There are no hard and fast rules except to not let technical debt get out of control!
As always I'd love to hear what you think about this article so feel free to either leave a comment below or reach out to me on twitter.