"The manual won't let me refactor my legacy code!" Common situation? Terribly annoying. The majority of developers sooner or later face a manager who is not at all interested in improving what is already ready. They either need to implement something new, or urgently put out the fire, or fix some bug ... In general, they will always find a reason to postpone the refactoring of the running code base.
And even when you try to explain to them the benefits of having a neat code, they either don't understand or don't want to understand. They only have costs and deadlines on their mind, and nobody cares about quality. And it turns out that you are absolutely powerless to do something with technical debt, which is still accumulating and accumulating. Programmers work for prod, and prod - for impatient user requests. Nobody will pay for refactoring. The situation looks hopeless.
In such a situation, many smart developers simply pack their things and leave the company. And very soon, because of the turnover in the department, the doors are no longer closed: some leave, others come ...
Managers are not programmers
The solution to the problem is to communicate to managers what impact poor code quality has on the business. Ultimately, the company's activities are aimed at making money. Arrived. Accordingly, management is looking for the best ways to cut costs and raise revenues. This means that in order to rehabilitate refactoring in their eyes, they will have to speak their language.
I happened to work as both a technical lead and a consultant, so I have a lot of experience in this business. Let's share with you some templates.
Five arguments you can give
1) "Refactoring will help reduce the volatility of the marginal cost per unit of software functionality,"
This is an exact quote from the remarkable performances of John. B. Rheinsberg at a conference on "Economics in software development." Wait, don't go! Everything that is said here, you know perfectly well, it is simply formulated in an abstract, abstruse spirit.
Let's go in order:
- "Refactoring will help reduce ..." - so far, everything is fine
- "... volatility ..." - in other words, unpredictability
- "... marginal cost ..." - that is, how much resource will be required to produce another additional unit
- “… Per unit of software functionality” is a feature that has value for business. Hooray! Business value is exactly what we need.
All five arguments are based on the same general idea of translation from one language to another, which we often neglect in dealing with people far from the IT sphere. Don't use slang, lean on concepts from economics and business - that's the whole secret ingredient. This will establish a connection between you and management faster.
2) "Over the past month, 63% of the development resource was spent on fixing problems with the quality of the product"
Well, substitute your numbers here. The point is to back up the message with quantitative data. Tech debt can't help but impact your day-to-day work processes. Can you prove it? Of course!
Here are a few metrics you can look at:
- . ? ?
- -, , . , ? ?
- , . ? ?
Show the management exactly what the bad code quality is for them. Better yet, find a way to convert those numbers into monetary value.
I once attended a post-mortem bug that could have been avoided if data type checking had been done. The code was written in JavaScript. At that time, there was a debate in the company about whether or not to switch to TypeScript.
The developers who understood what happened were not too lazy to raise the data and were able to assess the damage that the bug caused to the business. It turned out that in a few months of its existence, the bug sucked a million Canadian dollars from the company. Million! That alone would have been enough to offset the cost of switching to TypeScript.
Based on this, it was decided that the new services will be implemented in TypeScript, and for the most important ones, it is necessary to retroactively check the data types.
3) “From a technical point of view, we worked on credit to get the product out faster. Now we need to pay off part of the debt so that the time to market does not increase. ”
Again: we speak the language of the interlocutor. Metaphors can be very effective when you need to convey a message: they connect unfamiliar concepts with familiar ones for the listener and thus help to understand them. The concept of "credit" is well known to any manager. And "technical debt" itself is also a metaphor that has received wide circulation.
Or, let's say, imagine a company as a restaurant, and the codebase as its kitchen area. As dirty dishes accumulate, serving an increasing number of visitors becomes more and more difficult. Employees need to have time to wash dishes in between cooking.
4) "If you invest 10% of your time in code quality, your turnover will drop significantly."
So far, we've talked about the obvious consequences of poor code quality. But there is one insidious thing that's easy to overlook: turnover.
Companies these days have a hard time keeping developers, especially talented ones, on them. If such a person ceases to enjoy work, it will not be difficult for him to get another offer and just go wherever they look, away from eternal chaos. But what is there, perhaps you yourself are already looking around in search of something better ...
Now let's ask ourselves a question: what does the company cost to replace a resigned developer? A new specialist needs to be found, walked through the hiring process, and brought up to date. It takes investment, takes time and puts the whole team on hold. Management would definitely prefer not to do this kind of reshuffle every year. Therefore, reducing fluidity can be a serious argument. And the very fact of having a plan to eliminate technical debt will immediately give the whole team +100 to motivation.
5) "If you invest 20% of the resource in refactoring, FRT will be cut in half and ROI will be positive for developer productivity"
FRT is response time, an important metric for user support. Business strives to ensure that customers are satisfied with everything.
Here we do the following:
- Choosing metrics that have a lot of weight in technical support;
- We find a couple of problems that arise regularly and require developer intervention;
- We offer a plan to reduce the number of calls to technical support by eliminating the root cause.
- If these kinds of problems are resolved, developers will be less likely to be involved in customer support tasks. That is, they will free up more time than was spent on refactoring, which means that the investment will pay off - that very positive ROI.
Ultimately, they decide
Nobody can argue with that. I have offered five arguments to convince people of the importance of eliminating technical debt, but now I think there is one more piece of advice that needs to be given before you go to work on any manager.
Refactor as you go
Refactoring should not be seen as a separate phase of work on functionality. After all, you still cannot predict in advance what features will be implemented in the future. This means that you need to adjust the code base for new realities as they become available. This is also part of the work required to create that very material value - any professional developer will confirm this.
The rule works even for databases with legacy code. Well, okay, you will definitely not bring her into a divine form by tomorrow. And trying to do large-scale refactoring in-between is a dead issue too. But with this approach, the situation, at least, will not worsen. And when working with lrgacy code, you have to focus not on "good", but on "better".
Are you fixing a bug? Spend an extra hour writing an automated test. Are you getting ready to roll out a new feature? Take an extra day to clean up the code. Try to make the change painless day after day. After a few months, you will notice that this habit has had a huge impact on your productivity. Do you know why? Because refactoring helps reduce the volatility of marginal costs per unit of software functionality.