“Over time all code transforms from a
thing of beauty to unreadable spaghetti code”
Old proverb
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.
Best Practices
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.
No skunkworks
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)
Closing words
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.
Inga kommentarer:
Skicka en kommentar