We’ve all been there – pressure, project constraints, fast approaching deadlines, whatever the reason – the quickest, easiest implementation was chosen rather than the best overall solution. This results in extra development work in the future, also known as:
Technical Debt – extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution – technopedia.com
The value or benefit of the extra work is often quite clear to the developers working on the project. Chances are, they were the ones that wanted to build the best solution in the first place – project resources and timelines aren’t their concern, right? However, the benefits aren’t always clear to non-technical stakeholders or managers. Today we’ll be discussing tips for persuading non-technical managers to allow you or your team to address technical debt.
I recently attended ConFoo 2017 in Montreal where I sat in on Adam Juda’s session titled “Making the case for Refactoring to Non-Technical Managers”. I will be attempting to summarize what I learned from Adam’s session, while offering my own opinion on the subject. We’ll take a look at some less effective ways of asking, and then follow up with Adam Juda’s 4 step technique.
Asking or convincing a manager or stakeholder (especially a non-technical one) to allow you to spend time/resources addressing technical debt can be quite a daunting task. Often from their point of view, the work is already done – why would they want to spend even more money “re-doing” it. Let’s start by taking a comical look at some ways not to ask.
How not to ask
Complaining & Whining – making a mountain out of a mole hill
No one likes someone who is a chronic complainer or someone who makes a much bigger issue out of something that is in fact a much smaller issue than they perceive. Making your case for addressing technical debt by simply complaining about the status quo is bound to get you nowhere. Presenting a sound, professional argument with real metrics is a much better way to get what you want. We’ll talk more about this later in the post.
Begging – the Godfather mentality
If you haven’t watched the Godfather yet, stop what you are doing now. Go watch it. Seriously.
On a more serious note, I love this analogy. You really want to re-write that code or improve that process that’s been bugging you forever, so you get desperate and beg your project manager to let you. They might let you, but in some cases you may end up with strings attached. Now you owe them for letting you spend time on what you wanted to, even though it was most likely a benefit to the company in the first place. Why should you owe them a favor for improving a part of the business?
Hypotheticals – what ifs?
So you shouldn’t complain and you shouldn’t beg, well what if you give them a hypothetical?
You: “If we don’t improve this code, production might go down!”
Them: “If we don’t improve this code, production might stay up…”
Hypotheticals are usually ineffective in arguments, because the person on the other side of the argument can throw a contradicting hypothetical at you, and now you’re back at square one.
Being a Cowboy
Ever worked on a development team where someone thinks they are the greatest thing since sliced bread and goes ahead and pushes a bunch of work live without having anyone review it? Don’t be that person.
So your PM (or whoever) isn’t letting you address that technical debt. You think to yourself “I know, I’ll just do it secretly without them knowing”. Bad idea. When it comes time for a performance review or when it’s time to showcase what you’ve worked on, what are you going to show them? Worse – what if you push the changes live without approval and there’s a major bug. Now you’re the bad guy instead of a hero.
How to ask
So now that we’ve covered some ways not to ask let’s take a look at Adam Juda’s 4 step process that I believe to a very effective one.
1. Gather Information
Start by gathering information and metrics that you can use to build a solid case for addressing technical debt. For example: let’s say that you have a slow build process that you would like to speed up. Start pulling together some metrics such as:
- Average cost of developer per hour
- Time per build
- Builds per day/Builds per year
- Total hours spent running build process in a year
- Estimated hours of addressing technical debt
2. Calculate the Cost
Next take some of those metrics and calculate costs for addressing the technical debt. For example, say the current build process takes 20 minutes, and you wish to improve that process so that it will run in 1 minute:
- Hours to re-write build process = 40 hours
- Avg Cost of Developer per Hour = $40
- Cost of re-writing build process: 40 hours x $40 = $1,600
3. Calculate the Benefits
Next calculate what the benefits to the organization (continuing the example from above):
- 20 mins/build * 5 builds/day * 365 days/year = 608 hours/year
- 1 min/build * 5 builds/day * 365 days/year = 30 hours/year
- Yearly hours saved : 608-30 = 578 hours/year
Next dollarize! Everyone loves money, so represent your findings in a way that will really sell your case:
- Old build process: 608 hours/year * $40/hour = $24,320
- New build process: 30 hours/year * $40/hour = $1,200
- Total cost saved per year = $23,120 (after $1,600 investment)
I bet if you tell your PM/boss/whoever that you can save them $23,000 a year by only spending $1,600, you’ll have their attention. This is a much more effective way to make your case for refactoring or addressing technical debt than the ones discussed earlier in this post.
Next time you want to address technical debt and have to persuade a non-technical stakeholder, remember to not:
- Use Hypotheticals
- Be a Cowboy
Instead follow the 4 steps to building a sound, persuasive and enticing argument:
- Gather Information
- Calculate the Cost
- Calculate the Benefits
Thanks for reading!