Sometimes, my boss will complain to us:
Why do we need such a long time to implement a feature?
Actually, the feature has been implemented in another application before, you just need to copy and paste codes from there. The cost should be low.
It's really a hard question, because copy and paste codes is not such a simple thing in my point of view.
Do you have any good reasons to explain this to your non-technical boss?
copy and pasting is a disaster waiting to happen. Your boss should evaluate the price of shipping early with respect to the price of having broken code shipped to the end-user very soon.
If you find a bug in your copy-paste code, you will need to fix it every place you did and hope you can remember them all (this also holds for changed requirements).
If you keep logic in one place, it is easier to change when needed (so if you decide that the application needs updating, you only do it in one place).
Have your boss read about the DRY principle (Don't Repeat Yourself).
What you are describing sounds like the perfect use for libraries, where you share code and only keep it in one place.
I would only ever copy-paste code if I intended to refactor it soon after - making sure I later on extracted common code so I could reuse as much logic as possible. And by soon after, I mean minutes and hours later, not days and weeks.
You would be far better off sharing the code by building a library rather than copying the code using cut and paste.
You'll still gain a speed advantage over re-writing (look up DRY) but will only have one place to maintain the code.
If you have already implemented the features and you need to copy and paste to reuse them, it sounds like you have done something wrong. Can't you put these features in a library so you can reuse them without copy/paste?
The obvious reason is that you take on a 'debt' for the future: any change you ever need to make in the code (not just bugfixes, any change) will now be twice as expensive to do because you have to update two places - and more risky because you WILL forget one of them eventually. In other words, making it work faster now will make your work even slower in the future, which can be good business sense but usually isn't.
But the more important reason is that the assumption "this is the same as that" is more often than not subtly wrong. Whenever your code depends on unspoken assumptions to be correct, copying it into another place results in errors unless these assumptions also hold in the new place. Therefore, the pasted code is often wrong from the start and not just after the next change.
The DRY principle (Don't Repeat Yourself): DRY on wikipedia.
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
Copying and pasting code usually leads to Programming by Coincidence
I worked for a similar company. Being a trainee, I didn't know better then, so when I started a new project, my boss also suggested to paste the code from somewhere else. Well, as you may think, the whole software was quite a mess, up to the point that when you tried to fix a bug, two new bugs appeared.
Even if the other application already has the feature you need, the code for that feature might simply not fit into your current application without a major rewrite. It's like taking the motor of a Ford and trying to fit it into a Toyota. Generally, there is a rule of thumb that if you have to modify more than 25% of the code you copy, it's better (cheaper) to rewrite it from scratch.
Extracting the code in question into a library sound compelling, but it might be more difficult than it sounds, depending on how that other system is built. E.g. the code for that feature might be hard to extract because it interfaces a lot of other code in unclean ways (e.g. by accessing lots of global variables etc.)
Are you sure your boss wants to hear about DRY principle, bugs and other tech stuff?
That kind of comments you usually hear when your boss or company underestimated time needed to complete some release. And based on a wrong estimation a contract was signed, etc. In most cases programmers weren't involved into estimations.
Why this happens? Simply a project sponsor has too small budget. Maybe a business process you are automating using software isn't worth of your team effort. Managers generally tend to very closed for bad news in such cases. At the beginning of a project there is wishful thinking. Then managers try to blame programmers. In your case indirectly via copy-and-paste. In extreme cases this is called a death march.
Tell your boss that the part of the each and every variable name includes the name of the old project and now you have to change them all, manually. If your boss doesn't know (or wants to know) why copy/paste is bad he/she might as well believe that :)