As usual, there is merit to the opposite side too. Don't create some huge abstraction with class hierarchies and virtual methods and stuff, just to avoid cutting and pasting a ten-line function somewhere.
Often it's a good idea to start by cutting and pasting, and then afterwards figure out what ended up being sharable.
Agreed. I recall a useful rule-of-thumb that states you should wait until the third time you need a bit of code before packaging it into something reusable. Otherwise, you might be wasting your time.
This sounds like a rule-of-thumb for making sure bugs get fixed in one place but not another. :)
Seriously though, this article got me to thinking and I realized that why would one live with the smell of copy-and-paste when it's just so darn easy to write a singly reusable function?
I agree with what you in the sense that there's no need to go from what might be a few lines of copied code to a full-blown library or subsystem. But for a small bit of common code not refactoring that out immediately seems to me a really bad practice.
If you factor too early you end up with a function that takes ten parameters. Sometimes cut+paste functionality evolves into truly divergent code, and you have to have a "feel" for when it will happen.
You're positing a false choice; it's not either-or. The proper abstraction for a cut-and-pasted 10-line function is generally an 11-12 line function, with just enough extra complexity (i.e. an extra argument or two) to capture the differences in the two implementations.
The huge abstraction with class hierarchies is an entirely different kind of idiocy. It's orthogonal to this problem. You can (and I've seen it done) cut and paste giant class hierarchies too.
Often it's a good idea to start by cutting and pasting, and then afterwards figure out what ended up being sharable.