“Over time all code transforms from a thing of beauty to unreadable spaghetti code”
Wikipedia defines Technical Debt as follows
Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.
We all have an instinctual understanding of what it means, that it’s bad and that we should fix it as quickly as possible. So, why don’t we? The main reason is that our managers will not let us spend time refactoring until we have shipped the release. And when the release is shipped there is no time to refactor since we are now working on the next release and so on. And our debt increases and we spend more and more time working around deficiencies in our code base than we do on creating a better product.
Shipping the next version of the product is important, but over time the company will actually lose time and money by not handling technical debt. So how do you ensure that it will be paid off? A common argument I hear is “but my Manger understands that this must be done, and if he doesn’t then he does not deserve to be a dev. Manager”. Assume that this is true, and your manager understands the need. But he has to defend the schedule slip to his manger that may not understand it quite as well, and he must explain to someone else and so on. That leaves you with two choices. You can stick your head in the sand and say that if the company is not smart enough to understand this then they don’t deserve you. Or you can sell it to your management chain.
Your secret tool is a ROI calculation.
Find out, to the best of your ability, the following data points.
- How many engineering years are spent on the product per calendar year
- What percentage of the engineering time is wasted on technical debt
- If you could spend X, Y or Z (see below) man-months fixing technical debt, what would the waste percentage be then
What is X, Y and Z? It depends on the size of your projects. Y is the number of man months you would suggest as optimal. X is less than Y, let’s say half. Z is more, 50% or double.
Then, armed with this, you create powerpoints stating the following:
Where are we today? How much are we losing, in concrete numbers? Make sure that your estimates are the best you can come up with, and write down in speaker’s notes how you came up with them. The most important delivery of the presentation will not be you presenting to your boss, it will be your bosses boss presenting to his boss and he will need your notes.
Given three scenarios, where could we be? Be realistic. In this example I acknowledge that even with infinite time we would never reach 0% lost.
Summarize the findings. Include how long it will take to make up for lost time, as well as what the savings over a longer time, in this case 5 years, will be.
“Cost” is number of Engineering Years spent in the refactoring project.
“Savings Per Year” is how many Engineering Years will be saved per Calendar Year, in the form of reduced waste.
“ROI” is the number of months it will take until the time spent on refactoring will have been gained back by savings from having refactored. (In the example below – Spending 2 Engineering Years on a project that results in 3 EY/calendar year savings will have a break-even point
Great - You are almost done. Now make sure that the speaker’s notes have all the information that someone you never met needs to be able to perform your presentation.
Show your work
As you well know, the numbers on “percentage lost due to technical debt” and the estimate on how much this will be improved are estimates and guesses. For almost all cases it will be impossible to get perfect data, so the estimates is the best there is. Show your reasoning behind the estimates and put them in the speaker’s notes. And make sure that you really make your best guesses, not guesses that support what you want to do. A loss of trust here will be catastrophic.
The 90/10 rule
If your loss due to technical debt is less than 10% then it’s likely not worth the bother to try to fix. While 10% sounds like a lot, consider two things. One – It will never be 0% unless it’s a green field project. Two – If you are like me and everyone I know, you will tend to believe that the loss is little bit higher than it actually is. The exceptions are if it’s extremely well defined, like time spent waiting on testing to complete two times per day compared to time invested in a continuous integration system.
Keep it Short
Long refactoring projects are scary. Your chances of getting permission to do them increases a lot if you can keep them short. 3 to 6 months is a good rule of thumb based on the size of your projects. And having 1-2 engineers, or max 10% on the project also helps sell it.
A tempting solution is to just hide that you are doing refactoring from your management and just do what has to be done. This is a terrible solution, because when you get found out, and you will, there will be no trust left between you and your manager. (I’ll comment further on a related topic in another post, in 2019 if I keep this pace up)
Selling a refactoring project need not be hard. Just show why it will save time/money and understand that everyone involved needs to be able to cover their… err… needs to be able to justify the time expenditure on something that is not driving features.