Why Creating Tech Debt Is a Necessary Evil
Always building state-of-the-art solutions will cripple how you innovate
Always building state-of-the-art solutions will cripple how you innovate
Tech debt is something that used to drive me nuts. Developers pressured me to give them room to handle tech debt. They claimed everything could collapse if I wouldn’t listen to them. Meanwhile, demanding stakeholders wanted more output and didn’t understand why dealing with tech debt mattered, and unfortunately, I didn’t understand it either.
Does this scenario ring a bell for you? No worries, you’re not alone, and there’s a way out of that once you learn what to do and what not to.
In the past, I hated the term tech debt. I got so tired that I wanted to avoid all discussions related to this topic. It took me a while, but I understood my ignorance was getting in the way of helping teams become value maximizers.
Nothing teaches you more than painful experiences. And that I faced a lot in my journey.
Today, I see many ways of dealing with tech debt, but most will piss developers off and create a worse problem: mistrust. Yet, when you learn how and when to use tech debt, you have a higher chance of delivering value faster and avoiding investment into pointless initiatives.
By the end of this post, you will know why tech debt is a powerful tool when used wisely. I will also share approaches that don’t work and why you should avoid them. I hope you can benefit from these insights and apply them from today on.
Screwing Up With Tech Debt
Maybe you invest 20% of Sprints into reducing tech debt or dedicate whole Sprints for it. Perhaps you ignore it and put all your energy into shipping new features. Teams make these common choices to handle tech debt, and that’s where a bigger problem is born.
Before I elaborate on why such approaches often fail, we should understand what causes tech debt and what’s that at all. The cause is usually simple, speed up delivery of features by lowering code quality, e.g., scalability and maintainability. When Product Managers want to learn from real users, they push teams to create tech debt and address it later. What generally happens is that later becomes never, and the tech debt pile is ever increasing, which will create several side effects:
Legacy Code: Only those who worked on the feature can extend it and fix issues. Others would take too long to understand the code or be against working on it.
Low Motivation: Developers slowly get demotivated as the code quality deteriorates and feel powerless to change it. If nobody listens to them, they will search for something else sooner or later.
Bugs: The more corners the team cut, the more issues they will have. Bugs pop up, and the team gets busy fixing them and potentially worsening the tech debt situation.
Tech debt cannot be managed passively. It has to be done actively.
Teams struggle with tech debt when they react to issues instead of dealing with them proactively. Many developers write poor tech debt items and get angry with Product Managers when they refuse to get that into a Sprint. Don’t think that reporting an issue and putting it in your Product Backlog is enough to guarantee you will solve it later.
Bad Tech Debt Description
The following examples will convince no Product Manager to prioritize them:
Refactor recommendation engine
Move feature X to NoSQL
Rework on the Partner API
Good Tech Debt Description
If developers want tech debt to be addressed, they should help Product Managers understand the consequences of not doing them. For example:
Scale recommendation engine: The current solution was built to support ten thousand products, and now the shop has fifteen thousand. That slows down recommendations and increases page load time by three seconds. The conversion rate is potentially endangered.
Redesign Partner API: The partner API isn’t market standard. It was created a year ago and has not been touched since then. Partners take around a week to integrate with our platform, and this time could be reduced to a day with a simpler API that would allow partners to offer their products faster to our clients.
Storytelling is key to handle tech debt.
Mastering Tech Debt
Almost every team I know has a dilemma between building it right from the beginning of hacking and fixing it later. Both sides have advantages and disadvantages.
Considering the team invested proper time into discovering a solution that solves a meaningful problem. With solid evidence, the team is ready to implement the feature, and you can take a waterfallish approach, build everything right from the beginning, and release it to your audience.
When you opt to build it right up front and luck is on your side, you will have a great solution and won’t even bother with tech debt. However, we all know that no plan survives contact with real users. Things will go wrong. You may have invested too much upfront when that happens, and adapting your solution will become costly and slow.
By building it right up front, you might not have to worry about tech debt, but you will have high losses when things go wrong.
You can use tech debt as a tool to validate your solution. Even with solid evidence, you can only be certain something works when end-users benefit from it. My approach is the following:
Build to learn: Hack a solution as fast as possible. The goal is to confirm the solution is valuable to your audience.
Release to a small audience: Put your hacked solution live for a small percentage of your audience. Generally, one percent is enough to gain insights.
Measure and decide: Based on your insights, evaluate whether the solution is prominent or not and decide on improving and scaling or killing the initiative.
Gradual release: Increase the reach as you gain confidence.
Pay off created debt: After you prove your solution creates the expected value. Evaluate with your team the required investment to make the solution sustainable. Do the math and decide on paying the debt or dropping the initiative. You should not keep a poor solution alive. You should either do it right once you have enough confidence or dismiss it.
Whenever I present this approach to developers, they argue with me because they feel I am about to fool them. Their previous experiences don’t let them accept creating tech debt because they fear it will never be addressed once the expected business value is created. They are right. Most times, Product Managers jump to the next initiative once the result kicks in, though that’s not how you make a sustainable product. I do my best to gain their trust, and then it’s on me to walk the talk.
In my experience, the more you invest upfront, the more losses you face. This is obvious, but people ignore it. I encourage teams to be wise about tech debt. Remember the goal is to create value faster, and to do it, you must speed up your learning time.
The weaker the evidence, the smaller the investment. Use tech debt as a tool to create value instead of an issue that limits your product growth.
Final Thoughts
Collaboration is the best way of dealing with tech debt. I don’t think developers must beg Product Managers to prioritize tech debt issues. I believe everyone should have a single goal: improving people’s lives. When the goal is clear, you can evaluate how your actions contribute to it.
One of the biggest traps with building it right from the beginning is the illusion that everything will go as planned. Murphy’s law works pretty well, and if something can go wrong, it will go wrong.
Don’t let a plan illude you. Work as a Venture Capitalist, increase your investment as the evidence strengthens, and stop investing when expected results become unachievable.
Want to Connect?This story was originally published in GoRetro.