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?
Yeah, the biggest problem is that it isn't just copy and paste - its copy then paste then slightly modify.
Then later on when one of the pasted variants has a problem, it gets changed. Then later on, another variant gets changed.
Then, you find out that all the variants have to change cause the original copy had bugs. Now you are well and truly screwed because all the pasted areas are now not the same.
And wouldn't you know it, this kind of crappy coding is usually almost entirely void of comments.
To me, the difference is that when you have multiple copies of code doing the same thing, what you have is a bunch of code. When you only have one piece of code doing each particular thing, then you have a system.
Behaviors of a system can be changed with single point modifications quite easily - changing the behavior of a bunch of code requires a bunch of code.
I like systems, not a bunch of code.
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.
He's right that if the team has implemented similar functionality before, repeating it will be much easier the 2nd time.
However, you should probably explain that each application is different. Just because you installed a door in one house doesn't mean you can install another door in another house in no time flat - you will be faster because of the experience (# doors installed), but it will still take time to get you equipment, mount the door, make sure it is plumb, and screw it into the frame.
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 project. And based on wrong estimation a contract was signed, etc. In most cases programmers weren't involved into estimations.
Why this happens? Sometimes project sponsor has too small budget. Maybe a business process you are automating using software isn't worth your team effort. Managers generally tend to be very closed for bad news in such cases. At the beginning of the 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.
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.
I think "another application" is key here, if the other application is already tested and in use, it should not be changed to use a common library, therefore you can’t share code with it.
Within the same application, “copy and paste” is bad, but between code bases that are developed by different teams or with different release cycles “copy and paste” can be the best option.