Maintenance code. How to “sell” refactoring to business

A few days ago I wrote an article about the main characteristics of the old code. However, there were too few concrete practical recommendations on how to live in the conditions of the old code.

Today I will try to answer one of the most frequent questions that I hear when it comes to developing systems with an exorbitant amount of legacy, and share my view on how to “sell” refactoring to business.

In this article, I fundamentally limit myself to describing interaction with a business and do not touch on technical details (how exactly refactoring should be carried out). The post is written solely on the personal successful and not very experience of “selling” and “buying” refactoring in different teams and in different companies.

Prerequisites

So, to be more specific, let's imagine that we have a flagship product that has been operating for several (sometimes a dozen) years and brings the lion's share of the company's revenues.
')
Usually there are approximately the following features of the product:

• "Plasticine architecture" - during the lifetime of the product has acquired a large number of additional features that have been added in a hurry. This led to the fact that the logic of the system is evenly spread throughout the code, in some places there are "hacks" that allow you to "do strange", bypassing the original idea.
• lack of unit tests - the current logic is not covered by tests a little more than completely. “Because unit tests were thought about for the third year of the system’s life, but it’s already incomprehensible how to build in, and there was little time for the tests.”
• the absence of experts - people who initially wrote the product, either sit in the position of big managers, or quit, or have already forgotten for many years how everything is arranged inside.

I described a typical situation in which there is a huge amount of products in different companies. And, characteristically, the level of developers can be very high. Just every year the code becomes more and more confusing.

It is clear that such a code will have to refactor sooner or later. But how to get time for this task in the conditions of a constant flow of food tasks? That is what we will discuss below.

And can rewrite everything from scratch?

You can dream about it, but the chances that someone will be able to convince of this is extremely small. Moreover, if you manage to convince the management to throw out the old code and write it all over again, it means that either this manual does not know how to assess the risks, or the company is so rich that it can afford a long time (sometimes for several years) contain a parallel "strategic" team of programmers who do not bring current profits.

In general, read Joel Spolsky . He says it (although, according to the official version, Netscape was nevertheless taken out of the market by free IE, and not by delays in updates).

And one more thing: it is necessary to understand that the project “rewrite everything from scratch” can take years, and you will have to deal with the support of the old code at this time. Therefore, what is written below is important in any case.

So, how can you convince a business that you still need refactoring?

Tip 1. Do not sell refactoring to business!

In order to understand what I mean, we need to recall Fowler's classic definition: Refactoring is a change in the internal structure of the software, designed to make it easier to understand its work and simplify the modification without affecting the observed behavior .

Pay attention to two points:

• the purpose of refactoring is to simplify the understanding and modification of the code - purely technical, not business
• the behavior does not change, that is, the result for the business is not noticeable

This means that with the successful refactoring, there will be no changes. None! With less successful - in the running code there will be errors and differences in behavior. That is, you cannot say “we fixed 10 bugs and implemented a super chip”. You can say “now the code has become more beautiful, and the architecture is simpler and more understandable. Well, yes, and a couple of bugs appeared ... But we will definitely fix them! ”.

Now imagine yourself in the place of business. A team of expensive professionals spent a lot of time on "beauty guidance" instead of making understandable features that bring users and money. It's like, having given the car to the car wash, get it unchanged and the bill for $ 500 with a note “we went over your suspension and now we can change racks three times faster. Perhaps the first time will be something to tap, but it should pass in a month. If it doesn't, come, we will fix it for a reasonable fee. ” I do not know about you, but I would not like that very much.

In general, the first rule is this: they buy only what is interesting for the buyer or what you are interested in. Modification of the code itself is not valuable for business and is not interesting to anyone except developers . Therefore, the main mistake you can make is to say: “you need to do refactoring, because the code is bad, and nothing is clear.”

Then what to say?

Tip 2. Sell business opportunities and problem solving

I think each of us intuitively understands that problems with bad code lead not only to the pain of developers when working with it, but also to certain problems in business. If you try to formalize this understanding, then we come to the two most serious problems.

Firstly, it is an unstable system behavior - strange bugs, performance problems, unpredictable behavior, data loss (this is probably the worst) and so on. This, in turn, leads to user dissatisfaction, refusals, bad reviews, low ratings in the case of mobile applications. In general, it affects the profit in the most direct way.

Secondly - a very long process of making changes . That is, from the moment when the feature is conceived before it appears in the code, it takes a long time. As a result, this not only makes the development process long and painful for the product team, but also does not allow you to quickly derive many functions, experiment with a large number of different options, quickly prototype changes and roll out to users to look at their reaction. Moreover, sometimes some changes that you want to make are simply impossible without a careful reassembly of the entire system on cogs (and this is in fact already close to what we call refactoring).

Therefore, it is necessary to come to business with the idea of ​​refactoring at a time when at least one of these two problems becomes obvious. However, if there are no problems yet, and you see a potential danger in one of these areas, you can come to the business in advance. But then it is necessary to prepare a much more compelling arguments.

As a result, the purpose of refactoring should be stated not to improve the structure of the code, but to stabilize the system or speed up the delivery of features to users . Accordingly, if as a result of refactoring, there are no fewer bugs, and simple features, as they were added for two months, are added, then time was wasted, and, from a business point of view, you did not cope with the main task.

Tip 3. Take a look at the business development.

As it was already written above, the first rule of argumentation is to understand the values ​​of the interlocutor. In this case, it makes sense to look at refactoring from the business side.

From a business point of view, any feature has development costs and profit from implementation. Costs consist of several parts. First, it is the money that the team spends on the development of features. This includes developer salaries, taxes, office rent, equipment, electricity, and so on. The costs associated with the loss of profits are less obvious, but no less important: during the development of the current feature, no other functions appear in the product that do not make money and do not attract new users.

Obviously, the importance of features can be easily estimated by comparing the planned profit from it and the costs of its implementation. From this point of view, refactoring is an investment in the pure form. Resources are spent, but the product does not appear as a result of either new users or new functions.

And your main task is to show the business why investing in refactoring will benefit in a reasonable time .

How to show this benefit?

Tip 4. Use numbers

In order to make a decision on refactoring, a business needs, first, to get an estimate of the labor costs for carrying it out (which you most likely do regularly), and second, to understand the profit from its results. And this is one of the difficult moments. No matter how I would like to say: “we have many bugs” or “if we refactor, we can save time when making further changes,” these words will have no meaning for the business.

In order to come up with a normal numerical rationale, you will have to do some administrative work. For example, to collect in one list all the bugs that can not be fixed in a reasonable time in the current implementation, and which will be corrected after refactoring. A more difficult and painstaking work is to keep track of how long each change takes, and add time to each digit that would take this change in the system after refactoring. This is an order of magnitude more difficult, but the results are much more tangible. Because, “the change that would allow us to save X man-hours of development over the past month and allow us to save about the same in the future” sounds much clearer and more convincing for a business than the need to “put the code in order”.

There is another subtle point. In assessing, the main thing is not to embellish, not to make a bright future brighter than it will in fact not underestimate the cost of refactoring. After all, after the cherished "good" for refactoring is received, you will be the person who promised a bright future and spent the budget, and as a result ...

... and as a result, everything depends on you. If you are sure that refactoring can help catch old bugs, speed up development, make the code cleaner and clearer, and the user is happier, go ahead.

And good luck!