Let’s discuss Technical Debt
What is Technical Debt?
“Some problems with code are like financial debt. It’s OK to borrow against the future, as long as you pay it off”
Everyone knows it’s right there but they choose to ignore it unless it slows down the pace of execution or hampers productivity. Let’s call it out -
Code that is not quite right may include many types of issues but got compromised due to fast pace feature releases is generally known as Technical Debt. These issues may be related to architecture, structure, duplication, test coverage, comments and documentation, potential bugs, complexity, coding practices and style. All these types of issues incur “Technical Debt or TD” because they have a negative impact on productivity.
Are there different categories of TD?
There are various tables/types and categorisation defined over multiple tech blogs about TD but I’ve found and collected the below information based on my reads -
What can we do about it?
a) Define it
Sometimes developers and product managers disagree about what constitutes technical debt. So let’s put the controversy to bed right here. This includes any technical shortcuts made to meet delivery deadlines (Not all software projects issues are Technical Debt)
b) Analyse it
c) Educate the product owners
Tell them about the true cost of technical debt. Ensure future stories execution will be faster, if we dedicate time to resolve existing technical debt.
d) Modularize your architecture
Take a firm stance on technical debt in new components or libraries in the application. As the team and business see the agility in these new components, they will naturally want to extend those practices to other parts of the code.
e) Write automated tests!
Nothing prevents bugs better than automated tests and continuous integration. When a new bug is found, write a new test to reproduce it and then fix the issue. If that bug ever resurfaces, the automated test will catch it before customers do.
How do we handle “Technical Debt” at INGOMMT?
GO-MMT follows AGILE process to its core and thus we have created one general thumb rule i.e.
“Dedicate 10% of your stories in every alternate SPRINT to attack Technical Debt”
- We made sure our Product Team understands the significance of dedicating SPRINT bandwidth for Technical Debts Cleaning
- Take 10% or 1 story in at least 2 SPRINTs and label them “Technical” (Below image shows how to label these stories as Technical)
- Tech team always make sure there are enough “Technical” stories in the backlog to be picked up in future
For Product Team (Must read)
https://productcoalition.com/how-great-product-managers-deal-with-technical-debt-453edec3d473
References (Do read in leisure)
https://www.atlassian.com/agile/software-development/technical-debt
https://www.agilealliance.org/introduction-to-the-technical-debt-concept/
https://www.scrum.org/resources/blog/technical-debt-product-owners
My ask to all the tech leaders is to take a step back and discuss this in an open forum & if there is any other good approaches or best practices which the team follows to tackle “Technical Debt”, please share your learnings with us.
Happy to hear from other teams how they honour “Technical Debt”.
