How to explain to the client that copy-paste is bad?

Question

Programming

We are talking about copy-paste at the "from application to new application" level.
There is a site A with N features. He needed an additional site B (moreover, on a foreign domain), which contains N - 2 features from the previous one, and a couple of his own (in fact, more wrappers over the already existing ones from A).
A decision was made on site A to provide an API for B, so B will only have its own logic, and there is no need to re-implement existing features. As an option, move the code to a shared remote package (npm or github), but all that gives is additional package management and the need to set up an environment on the back for B.
As a result, the client does not like this idea, since changes to A or B can affect the second (which is quite right). Even though the features are about 90% the same. Arguments were given ranging from "bad practice" to having to make the same edits in two places, but they were all ignored. What to do in this situation?

Answer 1

that copy-paste is bad

who is bad?
Have you expressed your opinions? Fine. Now we do what you are paid for. There will be your own project with your own financing - you will do as you want.

Answer 2

I wouldn't call your situation a copy-paste. This is a fork of the project. In the new one, almost everything is the same, but slightly different features - and perhaps it will develop differently (well, or it will die quickly).
Moving feature commits between forks isn't difficult if you only have a couple of different features in the new one.

Answer 3

I recommend trying to explain to him again what bad practice is and why you want to do it. Refer to the authors that everyone knows: Frawler, Gang of Four and so on. If he does not understand (and I partially agree with him - it is possible that changes to the old project will be more expensive and more dangerous, especially if the old code is not covered by tests), then do as the client says. In this case, it is up to him to decide how to do it. You can also refuse to work with him.

Answer 4

Actually, the client is right.
If there are "common" parts, then they should be separated into a library/framework.
And this is a slightly different level of development.
And writing it is a little more difficult.
Therefore, in this case, a simple copy-paste is cheaper.

Answer 5

There is a site A with N features. He needed an additional site B (moreover, on a foreign domain), which contains N - 2 features from the previous one, and a couple of his own (in fact, more wrappers over the already existing ones from A).

You don't need to copy-paste anything.
We are making an abstract site O, in which there will be features common to A and B (the same N-2 from A).
Site A inherits site O + 2 features specific to A.
Site B inherits site O + 2 features specific to B.
That's it.
In the future, when developing something new, we look where to add it - if only for site A, then in A; if only for site B, then in B; if both there and there, then in O.
API is an extra connection between components, which in this case is redundant and harmful (as noted above, if site A crashes, this should not concern site B).

Answer 6

No way. If he is confident for some reason.
In part, we can talk about the rise in the cost of maintenance. But this (rising in price) will happen only on the condition that the common features throughout the project (lifetime of both sites) should be the same. If they will and should diverge over time, then copy-paste (fork) is the only solution. And then the client is very much right. Maybe he just doesn't want to talk about these considerations, but they are there.