Tech Debt: The Good and the Bad
“Think of technical debt as your software buddy. Good debt boosts you up, while bad debt can tie you down with ongoing problems. In this article, we’ll explore what technical debt means for your ability to work quickly and flexibly in the tech world.”
Debt involves taking something now and committing to give/pay it back later.
We can split the debt into two kinds, good and bad. Good debt is when you borrow money for things like education, which can make your future better. Bad debt is when you borrow for things like a fancy holiday or an expensive meal, which doesn’t give you much in return.
Good debt helps you and acts like a booster. Bad debt, with its interest, can trap you, making it hard to escape, and you can feel stuck and non-revertible.
According to Wikipedia
“Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”
In today’s software development, they use an iterative method called agile. This means that most of the time when a company makes a new software product, it starts with the simplest version which is the minimum viable product(MVP).
The most reason is that, if you are developing a software product, someone will definitely be ahead of you or the market is saturated when you try to release it with zero technical debt. Therefore, a strategically planned, and manageable debt can be used as a strategic move for improved time to market and cost-effective.
The tricky part about technical debt is that no one really tells you to fix it. People don’t call your customer service and say, “ Hey!, Change your way of doing things and you need to change your architecture.” They usually keep quiet as long as everything works fine. This can make it seem like everything is okay, but it’s not. This false sense makes the debt pile up, out of sight, until it becomes a big problem that can’t be fixed.
Gathering too much debt makes things slower, can make the team feel bad, and leads to problems like inefficiency. If you keep putting things off, it’s going to be really tough to deal with them later. As these issues pile up, it gets harder to manage them. The work slows down because the stuff you postponed messes up the code quality. You might even start to fear working on them, and it just keeps going wrong in a never-ending cycle.
Technical debt is one of the most important bottlenecks to technical agility. The important thing is,
- Knowing why and where tech debt is agreed upon.
- Transparency with the team, everyone should know it.
- Follow the best practices that you agreed on.
- Ensure properly documented tech debts, and proactively consolidate relatable things together.
I think agile teams should;
- Prioritize the tech debt with new features if it is relatable to areas of the design/architecture or development as much as possible.
- Do not use different backlogs or tracking for the tech debts.
- If there is increasing tech debt due to new features, try to re-assess/prioritize in ongoing planning sessions.
- If you are developing the product, you should have a good understanding of the business architecture/roadmap, the technical roadmap, and the end goal of the product. Then design the features not for the specific customer, but a wider range of users with better UX.
- Be a guideline and principle in your architectural principles to handle technical debts and important points aligned with your enterprise architecture. Then autonomous teams can learn from it and adjust their planings accordingly.
Keeping a steady flow of efforts to clear technical debt is important for staying flexible in technology. If you have other practices to share on this topic, I am happy to learn from you.
