How to Effectively Deal with Tech Debt
How to Effectively Deal with Tech Debt
A simple approach to stop suffering with tech debt discussions
How often do you hear one of the following?
Our tech debt is piling up. We must address it.
We need at least 20% of our Sprint capacity to deal with tech debt.
This code requires a refactor.
The more you stumble upon one of these points, the more opportunities you have the address tech debt more efficiently.
Tech debt was a topic that disturbed me a lot. I didn’t get why software engineers pressured me so much to give them space to deal with that. Of course, I challenged them on the need for that, but that didn’t get us any further. I had to do my homework.
Understanding Technical Debt
The reason I suffered the most was that I misunderstood tech debt.
Software engineers often use a car analogy that doesn't speak to me. They'd say, "Software is like a car. You need to change the oil, give frequent maintenance, or it will break." I don't see software as a car.
A car is a mechanic set of several components, which naturally have a lifespan. After that, you must change it. Software is a set o code achieving something, and if this something doesn't change, it should work forever. So why do we need tech debt that much?
I didn't get it for a long time, but now I get it. Let me share my understanding with you.
Tech debt is often generated due to diverse reasons. The most common ones are:
Pressure to deliver more: teams have no choice but to cut quality and continuously ship features at the speed of light
Poor coding standards: teams lack a meaningful code standard, and every software engineer creates code in a different way
You can find solutions for both parts, but you would still not benefit from what tech debt can create. Yes, I'm saying that tech debt is good. But only if you know how to use it
If you build everything perfectly from the beginning, you will create much waste because 9 out of 10 ideas will fail.
What You Can Do Today for a Better Tomorrow
Tech debt is a tool to accelerate learning. When you have an idea, you don't know whether that works. You need to speed up your learning. For that, tech debt comes in handy.
Build something to test your assumptions. Mindset: build fast, learn quickly.
Start small. Make your initial solutions available for a small audience and scale gradually.
Decide based on evidence. If your idea is great, scale that up. Otherwise, drop it and clean your code.
When you decide to scale up, you're still learning whether it worths the investment.
Pay the debt off once you discover your idea creates the value you want.
Paying the debt off is vital before starting to work on something else. Fail that, and you will get trapped with unbearable tech debt.
That's how I learned to deal with tech debt. It took me a while and some nerves. But now, I use it as a way to create value sooner.