''Is it possible that software is not like anything else, that it is meant to be discarded; that the whole point is to always see it as a soap bubble?'' AlanPerlis, quoted in the preface to '''StructureAndInterpretationOfComputerPrograms'''
----


PaulChisholm says: "What happens when the reusable
software is late?"

Rule 1 for reusable software: for software to be reusable, it must have been used.  

	* Do not agree to put a reusable software package that doesn't even exist on the critical path for your project.

Rule 2 for reusable software: reusable software is almost always over-engineered for your situation.

	* After all, it was written to solve "the general problem".  Before committing to use the allegedly reusable software, be very certain that it will really be more effective than just coding what you actually need.

--RonJeffries
----
AllanSchiffman had a wonderful rant about reusability. The heart of the story was a dramatic re-enactment of what happens when your barber reuses a lawn mower to cut your hair.
----
As the productivity of development approaches infinity, the value of reuse drops to zero.
----
Take a piece of paper.  Draw an empty graph box.  Label the vertical axis "Novelty of Technology" and the horizontal "Novelty of Application" -- the origin in the lower left is "Low" for both, the other ends of the axes are "High."  Draw a series of hyperbolas (four or five look nice).  Label them "Cost;" (or "Risk," or "Time") the one closest to the origin is "low," etc.

I first saw this chart as part of a benchmarking report at GE, and I think it's true here as well -- expect to spend dearly for applying a novel tool to a novel application.  It's counterintuitive, I suppose, since most people tend to think that the most advanced applications need the most advanced development tools, libraries, etc.  They may, but you should expect to pay dearly if you do.

KenMeltsner

----

Yup, and then there's the one about the Univac executive who capped the future number of possible computers at only a handful, and the assembly language programmers who scoffed at the first compilers, etc., etc..  Why assume that
something is never going to happen (or isn't happening already) because you haven't experienced it directly?

-----

I think the biggest force against reuse is granularity. What is the same and what is different often does not fall on clean boundaries or chunks or predictable sizes. Approaches to reuse like DeltaIsolation have this problem, for example. 

HelpersInsteadOfWrappers is a partial solution to the granularity problem. If you break the abstractions into smaller chunks, then you can mix, match, and change easier than a One-Size-Fits-All generic thing.

--------
See also: OoIsNotAboutReuse