How to explain to the client what technical debt and refactoring are?

Question

Project management

I stop working with some projects more than once due to the fact that I don’t want to work with a bad code base and I can’t change something.
I tried to explain this to clients and realized that this is a very complicated topic, until the fried rooster pecks, then no one moves.
I am mainly engaged in full-stack development of original products, on Django/Ror, sometimes these are quite complex applications, that is, not stamping sites using ready-made solutions.
Sometimes I take something for support, sometimes these are projects in which the code itself began to be written, but due to the fact that work is never done to improve the code after six months or a year, they become a burden, problems arise when evaluating estimates, incomprehensible bugs that are difficult catch other leaks, and all the bumps fall on the heads of the developers.
I would like to know how you live with it.

Answer 1

The client understands only the numbers, he does not care about the quality of the code exactly as long as the support of the code does not cost him a pretty penny. Give him real arguments FOR refactoring expressed as a profit in monetary terms and voila. Well, if there are no these arguments - only a personal attitude, then is refactoring necessary?
Well, since we are talking about numbers, clients and technical debt, how did you convince the client to pay you for the time to write tests? Do you include this during development when estimating the cost? What prevents laying and refactoring of critical places. Do you write tests? Then what kind of refactoring does it make sense to talk about? Then the arguments should be just reinforced concrete, so as not to waste time on a full test and the search for regressions.

Answer 2

First of all, why do you want to refactor the code at all? Moral satisfaction?! Technical debt?! Do you prefer to fuck with functions in code than with your girlfriend?
The code works - do not touch it, let it continue to work.
But if the client needs to make some special trick, for which you need to get into N * 100 classes, add processing of new input parameters, prescribe the formation and control of output data ... In general, it creates a lot of hemorrhoids, then you tell the client that it will rise in so many hours of your time and this will be the price tag, and if he agrees, you are already starting to refactor.
In general, somewhere I saw an opinion (here on a toaster or on codenet) that the client does not need to know at all that you are refactoring, which I personally agree with. You show him your hourly reports, the client sees that you are working, that's all. The rest is the little things that you save him as a specialist.

Answer 3

Whether to refach or not, it is solely your initiative, you will not be paid for it, you will not be able to persuade anyone to do it. So if the project is interesting or profitable, then you need to do well for yourself. Rewrite the places with the most problems. If not (not an interesting project, not profitable), then do not take it on. And here it is not particularly important whether you started the project yourself, or outsourced someone else.
I work in bloody Java Enterprise. Here refactoring does not stop, it is similar to renovation in a Soviet apartment. And it turns out to influence the customer only with "bows", i.e. we say, look what a cool report we're making you! And we ourselves think, to this tune, to refer our reporting mechanism.
Something like this)

Answer 4

How to explain? In a simple way.
You can't do a good thing the first time. You can achieve quality only from two, three or more times.
The task of the first stage is to get a working sample. It is good when it is fully operational, and even in operation. However, in order to get the opportunity * effective development - you need to work on quality, including inside.
Under *efficiencymeans greater results at less cost. In this regard, maintenance of unoptimized code obviously entails high costs, and most importantly, it leads to delays of unpredictable duration during debugging. If there is an intention to make the development more linear, and the costs are predictable, refactoring is needed. Namely, bringing the code base into a standardized form, optimizing the code structure, possibly getting rid of inherited bad decisions.
Costs include: financial support and development time, as well as the amount of work that managers do.

Answer 5

I don't see any problem in general. If the project that you got consists of shit code, and your task is not global, you can pile on crutches in the style of the previous expert and close the task with a clear conscience. If there are many tasks for the project, it is worth putting the issue of refactoring on the agenda, but since the task is global, it is unlikely that the issue will be approved. The option is to leave and find another project.
And if you can see that the code and structure are clean, then, of course, crutches are unacceptable.
The motivation here is exclusively payment, as in almost any job. And the best solution in order not to have to suffer is simply not to take self-written projects that were not made by you for support.

Answer 6

1. If refactoring is objectively necessary for the further life of the project (i.e., further development is extremely difficult without refactoring), then this is discussed and laid down in time. Argument: I will spend 2 days refactoring and 3 days developing, instead of spending 7 days developing and worse.
2. If refactoring is so critically unnecessary, but pitiful, then some separate most neglected classes are corrected along the way. Development time does not increase much.
3. In all other cases, refactoring is strong and not needed.
4. If you don't like the code from the very beginning, then it's better not to start the project.

Answer 7

Code quality is one of the least important factors for 90% of clients, with the exception of developer clients.
First, decide why you yourself need refactoring: for moral and ethical reasons, or is there a more specific "exhaust" from refactoring - will you throw out everything superfluous and the performance of the code itself will increase, or will you add new functionality faster? If both are unlikely and there are no other specific reasons, then it may not be worth it to refactor.
Sometimes we are engaged in "partisanism" - refactoring is carried out at the expense of other tasks.

Answer 8

We have to look at the situation. If you need some one-time minor revision and then no one will touch this code for another year, then it’s easier to make a crutch that solves the problem in a couple of hours. If serious improvements are planned and a lot of changes will have to be made, then you just need to honestly explain to the client that investing in refactoring now will help him save money later on improvements.
Those. the client must see the benefit for himself.
In such a situation, I explained to the client that the current code does not provide for a normal extension to add new functionality and, figuratively speaking, either we are now spending 30 hours refactoring and rewriting the code so that it is flexible and can be developed and easily implemented new functionality, or we in 20 hours we do everything with the help of crutches and then for another couple of months we catch bugs that pop up in unexpected places and spend another 20 hours on fixing them (most likely with regular crutches).

Answer 9

There are 2 options:
1. Discuss with the client and justify to him that after refactoring, 2 + 2 will be equal to 3 for him, and not 5 as it is now.
2. Hide these works by smearing them in a thin layer over other tasks. In this case, you do not tell the customer anything.

Answer 10

IMHO, refactoring is needed, the main thing is to understand why it is needed and whether it solves your problems or the problems of the client. If yours - then you do it "quietly", laying it in the estimate, if it solves the client's problems - you can try to sell this business "separately", but you will also have to take responsibility "separately", but do you need it?
Set the deadlines higher, explaining the increased complexity of the code, and offer that you can clean up the mess for so much, and the client will win after so much.

Answer 11

Sometimes we called it testing and put in time for this.
Sometimes they said directly that you can’t do a difficult thing the first time, any software constantly releases updates, yours is no exception.
But in any case, you need to explain what the result will be and why. Just refactoring if everything works and the client likes it will not work :)