The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

When it’s a good Idea to cut&paste

Following idea might sound very trivial, but I’ve seen so many examples of colleagues not grasping such a simple concept it finally convinced me – this is worth to discuss.
Let’s take a look on typical situation: we need similar, if not the same, functionality in 2 parts of the application (e.g. just need to add one more similar module)… hence design alternatives: cut&paste this code or use existing one. I’ve seen results of such decisions as well as process in progress and realized what often people tend to think: there a universal answer to this question.
 Some folks just cut&paste all the time and this approach surely works… it just often generates several times more code than it could be
More code is not very bad by itself (although also impacts maintainability), but bug in cut&pasted logic have to be fixed in N places and after a while nobody will remember all these places.
from other side folks (especially one that freshly graduated from OOD classes) strongly believe in “cut&paste for losers who don’t know about inheritance“... since requirements tend to change dramatically for things that seemed to be the same or very similar at first iteration this approach might  fail or require enormous efforts, good regression testing, etc.
As number of changes (dissimilarities) grow these code becoming incredibly complex (full of work-arounds, patches and simply unmanageable number of “if “statements). It’s amazing how far people could go for just one reason –to keep same code working for all scenarios before they realize it’s time to redesign everything. There also one more aspect in it – regression tests often done only for system we changing and code reuse across systems could break something happily functioned for years.
By now my point is, probably, clear: cut&paste or use – not a single answer, it is a judgment call.
Main driving factor is answer to the question: does this code _must work exactly the same way_?  For example we trying to decide to copy or use function calacABC in product A and B 
clear cut use:
In the long run this code have to work in the same way – in other words if we will change calacABC in product A this change also have to be done in product B. 

Now if it’s the same/similar functionality, but serves different business scenarios it not so clear
Products could evolve and require different handling.. for example all the sudden in product B calacABC have to be changed although in product A it should function the old way.
It still might make sense to use. Driving factors (beside likelihood of dissimilarities) is
-    is calacABC  from product A mature, well-tested  (+ to copy) or both products in active development and likely will go through rounds of bug-fixing (+ to use)
-    do we have good regression testing so affecting product A by changes in common code done for product B will be detected in time (might be not just + to use, but mandatory requirement )

Typically hint on which way to go could be found in business requirements or it’s matter of simple question to domain expert.. from other side often nobody around knows subject deep enough and/or how thing will be changing over time.. so, if you clueless
It generally more safe to copy, I would use if and only if you a) ready to refractor b) you sure nobody will brake one project while fixing the other e.g. same person(s) working on both  modules/productr lines/etc. or this person(s) able to communicate well enough + regression testing will catch it.

Just few words on what I meant under
USE – call directly (like call library function or extend base class) or via some interface
COPY – duplication of code in same code base as well as branching. Since branching, essentially, just special case of cut&paste (hopefully backed by tool-support) it inherits +/- of this approach.
Sergey Send private email
Friday, October 06, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz