Reusability is not a design goal

http://xkcd.com/974/

When software reusability is a stated goal of a software system, it encourages fitting your customers' problem to your solution's implementation rather than the other way around.

Reuse viewed as an intrinsic good encourages design missteps such as favoring inheritance over composition, resulting in tight-coupling issues.

Finally, reuse as its own goal violates YAGNI (You Aren't Going to Need It). See this great Coding Horror article, which really steals a bunch of my thunder.

Reuse has its place. Reuse occurs while following a more powerful design principle: Don't Repeat Yourself (DRY). Each piece of information in and about a system should have exactly one canonical location. Well-designed systems thus reuse their own components in the service of DRY, but what we should emulate in designing our own systems is not the reuse but the single encoding of each idea in a system.

"Okay, Mr. Smarty-Pants: Doesn't the existence and widespread use of software libraries contradict the entire point of this article? Haven't you heard of Ruby on Rails? Spring? Java? .NET?"

These are products for use by software developers (e.g. the Java Collections library). Within effective software libraries, reuse is still incidental to the more powerful DRY principle. Libraries are still designed to serve an end. Reuse comes naturally when common instances of a problem occur via DRY, not via the inherent goodness of reuse.