Convincing My Manager to Deal With Technical Debt
ByOn February 25, 2013 At 11:38 pm
A question was recently posted on StackExchange asking the following: “Should I try to persuade my manager that code tidying should take priority over meeting deadlines?” And if so, what is the best way to go about it?
The answers that have been posted in response to this question have brought up a common dilemma: How much time should we be focusing on dealing with Technical Debt at the expense of getting software out the door faster? After reading this post, there are a couple of questions that need to be answered before we want to persuade our manager on this:
- How far away are we from the release? It’s never a good idea to be touching working code in the last couple of weeks before a release, unless it is involves fixing critical bugs. In this case, your best bet is to schedule a post-release analysis with your manager where you can go over the things that did and didn’t go well
- If you do not prioritize the code tidying right now, to what extent will it impact future release deadlines? There is a reason we can associate messy code with the metaphor “Technical Debt” – because interest is accumulated over time making the messy code harder for us to deal with. If the bug seems critical, then it is important to explain the potential impact it could have on your systems to your manager. This being said, one should never forget that Technical Debt is essentially a tool that is used to gain a competitive advantage in the market, coding fast before competitors can do the same. There is no such thing as a system with 0$ worth of Technical Debt, so prioritizing the things that need to be fixed is an important step of dealing with it.
Actually going about and convincing your manager that dealing with Technical Debt is a priority is another dilemma. This question actually came up during an interview I did recently with Johanna Rothman where we asked how you can convince your manager that taking care of Technical Debt needs to be prioritized at the expense of adding new features. The conclusion was that it all boils down to data: track your velocity or your cumulative flow over time to be able to show concrete data that it will take you longer and longer to push out features if the coding issues are not dealt with. When you present this to your manager, it will surely have some persuasion on him as to whether you should be prioritizing code cleaning over meeting release deadlines.