The paradox of reusable code.

The dream of code reuse has been with us for quite sometime. It promises to speed up the time it takes to write a given project and, even more important, it also promises sturdy, well tested components that may overtime become completely free of bugs. This is what people mean when they talk about modularity. Well, as Rosenberg explains in his book, code reuse is widespread these days and it does contribute towards solving some of the problems programmers had to deal with in the past —especially, it does speed up the time to completion. However, it is not free of its own problems.

Here is one of the paradoxes of the reusable software dream that programmers keep rediscovering: There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won't handle are the very parts that make your new projects different, unique, innovative —and they're why you're building it in the first place.

(Rosenberg: p. 102)

This is almost by definition. A reusable component exists because a relatively high amount of people had a particular need in the past and it was written to satisfy that need. However, any project that is truly unique and innovative will have, by definition, needs that didn't exist before. It's one of those doh moments, isn't it?

However, there is another face to this paradox that's even more worrisome. What happens if a given project decides to use a particular reusable component from the get-go and later on finds the need to innovate and/or make some deep changes? Either they have to invest the time to learn the component —and we are talking about large and difficult pieces of programming here, such as Zope— or they have no other choice but to shoehorn their innovations into it. Needless to say, this leads to more bugs and, eventually, to an unmaintanable project.