Effectively Managing a Technical Debt Backlog
We’ve all been there. It is 5:58 on a Friday. Your office is empty save you, a few of your coworkers, and, of course, your Project Manager. She looks on earnestly as she awaits your fix for the production bug that is stopping users from being able to place orders, you know, the most critical portion of your app. And finally after what seemed like an eternity of searching, you find the problematic code. And you see the problem. This code is crap. For whatever reason (justified or not), the previous developer left this code in a hard to read, error-prone state and now you have two choices: either spend the six hours to architect and re-write this entire section of code while your users, and ultimately your brand, suffer as they have to wait an entire weekend for a fix or spend 10 minutes building on top of what is already there allowing you to push out a build that makes your stakeholders and users happy. In the scenario above, it is likely you will choose option 2. Ship the code as is with your fix on top of it and make a note to yourself to refactor this sometime next week. This scenario is the ideal breeding ground for Technical Debt and it is up to us as developers to manage this technical debt effectively.
Analogous to financial debt, if managed correctly, technical debt is not necessarily a bad thing. However, the cost of addressing technical debt increases with time and therefore must be addressed with some urgency. A great way to effectively manage long term debt is to maintain a list of Technical Debt tickets in the product backlog, alongside feature and bug tickets. Here is a list of tips for maintaining such a log of work and incorporating them into your current project’s workflow.
Maintain only one list
In most software projects, the project Manager maintains a list of work used to manage upcoming bugs, features and other tasks related to the project — the project backlog.
The backlog should also be used to store any and all technical debt tickets you create. Do not use the TODO feature of your IDE (for long term management) nor a different project on your issue tracker. By separating your technical debt tickets to a separate list you instantly de-prioritize your technical debt work in comparison to the rest of the tasks that you have to accomplish.
Keeping your technical debt ticket in the same list as your regular tickets also raises the awareness of the aforementioned technical debt tickets as now they are on the same list of tasks that the rest of the team are now using. Building team awareness will greatly aid in the management of technical debt because the quality of the codebase directly affects everyone on the team. Lower quality code usually leads to more production fires, increased QA cycles and higher development times.
Continually evaluate the priority of technical debt tickets
The technical debt tickets included in a sprint — a time-boxed period to complete an agreed upon set of tasks — should be well aligned with the goals of that sprint and the critical features of the product.
You (and the rest of your team) will quickly lose appreciation for the technical debt list if the subset you are working on does not reflect the current and most pressing issues of the codebase. Before each sprint planning meeting (or whenever you get together as a group and decide to discuss what will be worked on next), you should prioritize what technical debt tickets you plan to get to next. I like to think of each ticket via a (albeit a subjective) formula akin to timeSavedInFutureMaintance/numberOfHoursToFix and prioritize based on that. If you have some bad code in a part of you app that is not likely to change, I would definitely de-prioritize that in relation to bad code that is found in features that seem to be constantly changing by the business.
Once you have your technical debt tickets set up in this priority queue fashion, it is important to maintain verbose descriptions of the issue as you see it and discuss with the other members of the team that have to interact with the questionable codebase. What is an obvious issue to you may not be so obvious to a different developer on the project nor may they share your view point on the issue. Technical debt ticket grooming is a great forum to have discussions about code base quality, best programming practices in general, and to learn from our programming mistakes.
Also remember to verify that technical debt tickets are still valid at the time you perform your backlog grooming. Unlike other types of tickets, technical debt tickets have a good chance of just being completed by another developer who also noticed the issue and happen to have a good amount of time on his hands.
Spread awareness about the cost of technical debt
Project Managers have to juggle huge amounts of responsibility. They nurture and translate the demands of the business into nice modular pieces of tasks for developers to work on, have to deal with push back from developers as we bemoan deadline expectations and have to console business when the inevitable production fire occurs. So you should not be surprised when they leave your brand new technical debt tickets to sit in the backlog.
It is up to us, the developers, to stress why such tickets should not be left to sit in the backlog. With the exception of programmers, team members don’t immediately understand how investing 4 hours to remove duplicate code can save us days of work later on by reducing QA cycles as we only update erroneous code in one place as opposed to the three different places that have the same erroneous code. In Software projects , being the way they are, technical debt tickets will always be the first to be de-pritoritize, there is nothing wrong with this. But should this continue to be a trend during your sprint planning meetings where none of your tickets are technical debt tickets are being addressed, that represents a real problem. I believe if you can give 10% (half a day per week) of your time towards improving your codebase quality than you have a pretty good balance. If there is no time to invest in repairing your codebase, that may be a good indicator of a software project that is building out features faster than can be maintained long term.
In Summary
In summary, educating the team about technical debut while also adding and properly prioritizing technical debt tickets to the project backlog will ultimately lead to a healthier codebase — it will be easier to maintain and extend in the long run.
Do you maintain a technical debt backlog? If not, why? And If so, then please feel free to reach out to me and share some tips you use to effectively manage your technical debt!
