Summary
In the fairly famous "Defense Science Board Task Force on Military Software" released in the late 1980s, recommedation 29 was to "...develop economic incentives...to allow contractors to profit from offering modules for reuse..."

(I found this in Software Conflict 2.0 by Robert L. Glass, d.* books, 2006)

Years ago I was called in to consult on a project that had gone bad. The customer had engaged a contractor to develop the software, which was supposed to take a year and was at the time I was called in, a year late.

The main design and technical problem (ignoring for the moment Weinberg's maxim that "No matter what they tell you, it's always a people problem") was that the contractor had decided that this was an opportunity to develop a reusable software system, and that they could develop this system on the customer's dime.

This resulted in classic framework-itis. The contractor was no longer just trying to solve the customer's problem, they were trying to solve all problems that looked like it. So for that reason alone the project would have required 10x the original time and money.

And of course we are unable to avoid the people problem for very long: The architecture had many fundamental flaws, and one very big one resulting from a misunderstanding and assumed overlap between OO objects and Windows messages. This happened because there was one technical lead who was the architect, and who ruled with an iron fist and fired anyone who disagreed with him (and so everyone left was willing to agree with him). And he didn't understand as much as he thought he did.

Framework-itis in general is one way, and probably the most highly-criticized way, that attempts to reuse code go bad.

I postulate that most of the corruption in code resue comes when someone decides ahead of time that we should reuse code. That is, when it is driven by perception rather than need. I have personally found reusable code at the point when I need it a second time, as a process of discovery. And usually it's something I can't anticipate, or at least don't anticipate it in exactly the way that I need it.

Another well-known, and incredibly expensive for the industry as a whole, example of bad code reuse and framework-itis gone awry is EJB1/2 (EJB3 appears to be a completely different beast, riding on the questionable preexisting marketing of EJB). This was designed for an imaginary development process that had never happened before and apparently never happened during the life of EJB1/2, so developers ended up fighting against the framework rather than being aided by it. And I've heard numerous stories of companies having to rip EJB out of their system. Talk about expensive.

I think libraries can also fall prey to bad reuse scenarios. Again, setting out to create reusable code seems to be the culprit, along with imagining how a library will be reused rather than discovering how a library is reused. The great majority of the Python library, in my opinion, has been included after components have been used successfully in practice, and have evolved into a stable state. One notable exception, as I understand it, is the xmllib which was discovered to be un-Pythonic and messy/noisy to use, and the much cleaner elementree is being substituted in Python 2.5.

What experiences have you had when attempts at reuse have gone bad? Do you agree with me that those experiences came primarily from driving the "reuse cart" before the "use horse?"

Talk Back!

Have an opinion? Readers have already posted 56 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.