Why is "copy and paste" of code dangerous? [closed]

Question

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?

Thimerosal

it sort of sounds like rather than copying and pasting code from your previous applications into a new one, you are rewriting the same functionality again and again. I think the DRY principle is geared more towards not having the same functionality duplicated throughout an entire system, but re-using code from other applications is better than re-writing it. – Cataphyll

Because every time you copy and paste code, a baby seal is killed. – Gurgitation

@CarsonMyers Only if the component is reusable. And it is meant to fit in the current context. – Etana

Answer 1

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.

Bortz

+1. The point is that copy and paste is cheap for solving the immediate problem. The real issue is that in the medium/long term the cost of maintaining duplicated code is far higher than well-factored code – Clung

It isn't just a bug issue; program requirements can change. I've changed four out of five places where something needed to be changed before. – Ripply

If you can copy-n-paste on demand, and track where the duplicates are easily to either later abstract them or update them, then copy and paste isn't a bad thing to do. See discussion on clone detection at www.semanticdesigns.com/Products/Clone for further details and for tools than can do this. – Herc

Lots of ifs there, and most tooling doesn't support clone detection at this point. – Bortz

@Oded: There are lots of clone detection tools: #546987 – Herc

@Paolo, but isn't the here-and-now all that "business-types" are concerned with? They've learned to bank on the fact that they'll be moved on to some other position or department or job before "it" hits the fan. – Unwarrantable

@Downvoter - care to comment? – Bortz

Just tell your boss that you're the software professional and as someone who wishes to upholds standards to make the codebase maintainable in the long-run, you're not prepared to cut corners unless there's a very good reason to do so. If you have to cut corners, make sure you add unit tests and then you simply must go back and refactor afterwards when the heat is off. – Chine

Once upon a time there was a programmer who work for ESA. He was working on software for Ariane-5 rocket and he used copy-paste method. Then s... happens – Hephzipa

Answer 2

You would be far better off sharing the code by building a library rather than copying the code using copy 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.

Wilterdink

I'm just curious, why would you "cut" the code if all you need to do is duplicate it? – Ritchey

Good point dpp. Edited! – Wilterdink

Answer 3

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.

Croat

Answer 4

Design-wise, copy-pasted code is certainly a disaster, with the potential to cause lots of problems in the future. But you're asking why it takes you a lot of work right now, the answer is: because it's never just copying and pasting.

If the original code was written in order to be reused, as a fairly independent library, with flexibility and client use in mind - then great, but that's not copy-pasting, that's using a code library. Real code copy-pasting usually goes more like this:

• "Sure, I've already got code that does exactly that!"
• "Wait, which of these five versions of code is the one I want to use as my source?"
• "Hmmm, what do all these 'util_func_023' functions do? Didn't I document them? Which of them do I need now?"
• "Oh, yeah, this code uses Code Base Y. Guess I need to [choose one: copy all of Code Base Y into my new project / spend a day extricating the one function I want from Code Base Y / spend a week extricating the one function I want from Code Base Y]."
• "I copied everything, yay!"
• "Why isn't this working?"
• This is the point where you spend hours/days/weeks debugging existing code that is similar to what you want, instead of writing the code you actually want to begin with.

In summary, existing code which can't be used directly can, at best, serve as a good reference for writing similar code. It certainly can't be lifted whole and expected to work in a completely different system. In general, it's a safe assumption that any code which has been written and completed, should be messed with as little as possible - even when it's a copy and not the original itself.

If you want to base your project on copy-pasting, you've got to code to begin with in a manner that will enable easy reuse, without copying that original code and messing around with it. That's worth doing, and if that's what your boss is expecting, then you both need to make sure that that's how you design and work in the first place.

Scrutineer

Answer 5

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.

Samuel

Answer 6

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?

Upthrow

Answer 7

The DRY principle (Don't Repeat Yourself): DRY on wikipedia.

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

other link.

Mel

This is like saying, "never stick a knife in a man's throat", which sounds like a very good rule. Until you realize that the doctor MUST break this rule to perform the trachiotomy to save a man's life (if he can't breathe, perhaps due to anaphylaxis, extreme allergic reaction). Every rule has an exception (except, perhaps, for this one -- that every rule has an exception). Therefore, every rule must have a why and a when and an exceptions list, all attached, for the true "engineering" reality that the true answer is, it depends... – Kiwi

So... when do you NOT follow DRY? I constantly wrestle with this at my current job, which has to do with firmware, and the answer is that we "unroll loops" and do other things because that "improves performance." We have a very shallow inheritance hierarchy, and we use most classes directly instead of subclassing them, and... ...we use copy-and-paste a lot. And I hate it, because it makes our code base harder to understand and harder to maintain. But we have our reasons, and they are acceptable reasons. We are not the only stakeholders. And finding the right balance is more of an art. – Kiwi

Answer 8

It sounds to me like the worst misconception your non-technical boss has, is that your job is predominantly typing. They think you can save a lot of time by eliminating typing.

I think the best education you could give this person is to point out all of the work you do that isn't typing. Even if most of that work usually happens invisibly, in your head, at the same time as typing.

Sure, eliminating the typing will save some time. But then the much larger, non-typing, part of your job gets bigger and eats up any time saving and more besides.

Robedechambre

Answer 9

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.

Conceit

Answer 10

Copying and pasting code usually leads to Programming by Coincidence

Doolittle

I find this article exceptionally badly written. The narrative stays abstract thus fails to shed light on the case beyond the fact that Fred is working iteratively. One obvious problem Fred has is that he has no good idea of the overall architecture. Unfortunately, this is very often the case when we work with undocumented legacy code where the know-how is lost. References to Design by Contract and Assertive Programming are quite good, but unfortunately even after them the examples/exercises are left unexplained. – Keegan

Answer 11

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.

Hooker

While I can see that there is little point in releasing an update to the other application just to use the library, it would probably be a good idea to at least make a stab at the necessary changes in a feature branch. This would give you some confidence that the library's interface was general enough for at least the two applications in question, and allow you to merge the change at an appropriate point in the release cycle. – Visitor

Answer 12

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.

Philcox

Answer 13

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.)

Interfluve

Answer 14

There are trade-offs between speed of development of the immediate functionality in front of you (especially when the application is small), and longer term maintenance costs as the application grows.

Copy and paste is quicker for the immediate functionality, but will costs you dearly as the application grows in size, in terms of fixing bugs and making system wide changes and maintaining workflows between different components of the application.

That is the argument that business owners need to hear. It is similar to the accepted costs of maintaining a fleet of vehicles, however, with software, the broken aspects of the software architecture are generally hidden to the business side, and can only be seen by developers.

Phonation

Answer 15

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 :)

Roundlet

Answer 16

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.

Spiculate

Answer 17

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.

Luing

Answer 18

in my company, we always work with classes and methods, and make technical documentation for them. I think its the best practice if u can use your own svn search aplications with good keys to find method class used before :)

Heyer