Product Managers' worst nightmare →Technical debt 😱. How to tackle it?
Last week my Engineering Manager pinged me for a quick huddle & said “ Rohit, we won’t be able to take any new development or feature request for the next 2 sprints”. I was slightly taken aback but I definitely saw it coming. My engineering counterpart continued “ Technical debt has gone out of hands & we need to invest resources in code refactoring & ensuring that already built features can be made live keeping in mind the anticipated scale “.
I had no choice but to relent to this request but it has definitely led to humongous learnings & in this article, I will share a few approaches to tackle technical debt in the most prudent manner.
What is Technical Debt?
Technical debt is a phrase originally coined by software developer, Ward Cunningham. Technical debt (also known as tech debt or code debt) is the concept that developing features quickly will create bugs, and eventually, cause future tasks to take more time, or require additional engineering effort. Effectively, it’s the result of prioritizing speedy delivery over perfect code.
Let’s go through the common examples of tech debt :
- Frontend developers implement hard-coded flow instead of an ideal flow to save time & deliver fast.
- Lack of proper technical documentation
- Manual testing instead of automated testing
- Poor architecture design
Types of Technical Debt
There are three main types of tech debt :
1️⃣ Conscious Technical Debt
In the majority of the scenarios, the quick way is the right way (to avoid over-engineering), but at times the team will intentionally do something the “incorrect” way because they need to quickly deliver the product to the market.
While following this path, consider not only how much time you’ll save on launching a feature, but also what it will take to repay the explicitly acquired debt. It’s imperative to inform the stakeholders that future feature delivery will be impacted by following this path.
How to address this?
Religiously track this type of tech debt in the backlog. Assign a specific bandwidth to address this Sprint over Sprint. Product Managers and stakeholders should be responsible to ensure that the repercussions are owned by them and accordingly future features will require additional effort.
2️⃣ Unintended Technical Debt
As systems evolve and requirements change, the dev team might assess that the old design is flawed, or that new functionality has become cumbersome and slow to implement. This type of debt usually happens when teams choose tools they know well or like, rather than the tools which will do complete justice to the requirement.
How to address this?
A diligent & strict refactoring schedule is needed to ensure that this type of tech debt is accommodated as it’s incurred by design decisions and frequently changing requirements. Also following a rigorous QA and automated test development can help to curb such issues from even happening in the first place.
3️⃣ Bit Rot Technical Debt
Bit rot tech debt refers to the gradual devolution of code into unnecessary complexity due to tons of incremental changes & multiple hands working on the same code independently.
How to address it:
The development team should be accountable for avoiding bit rot tech debt as it’s incurred by individual developers. Accessing your dev team’s level of understanding & rigorously following code review practice so as to ensure that the quality of the shipped code is at par.
Thanks for reading! If you’ve got ideas to contribute to this conversation please comment. If you like what you read and want to see more, clap me some love! Follow here, or connect with me on LinkedIn or Twitter.
Do check out exclusive Product Management resources 👇
- The Ultimate List of 100+ Product Management tools 🛠https://rohitverma.gumroad.com/l/PM-tools
- The Ultimate List of Product Management Frameworks ⚙️
https://rohitverma.gumroad.com/l/PM-frameworks - The most exhaustive OKRs notion template 📔https://rohitverma.gumroad.com/l/OKR-Template
