10/4/99 - Jack Harich - Go Back
I received this email from Tom Loy on October 3, 1999:
> BTW, have you seen the latest Software Development magazine. There > is an article about how software reuse isn't economically viable > (among other points). The author does present a resonable argument. > I'll be curious about your reactions.So I immediately read the article - "Whatever Happened to Reuse" by Steve Adolph, Software Development, November 1999. It was thoughtful, stuck to facts, and tried to learn why reuse has failed so far. It's arguments were reasonable. Here's a summary of the article's main points:
1. "When you ask why they (companies adopting OO) are investing in object technology, they usually answer that they want to improve productivity through reuse".
2. "Today, most cases of reuse are actually software salvage".
3. "Component vendors must either seek the lowest common denominator in their customer components or let the client modify the components. Most experts agree that if more than 20% of a component must be reworked for its new context, it is more efficient to start from scratch."
4. "Systematic reuse for many companies is not economically justifiable beause of the high up-front costs."
5. "Much software is simply not reusable. There are many common concepts, but few common components".
6. Most companies are short term oriented and cannot focus on long term opportunities such as the high initial investment required for reuse.
This leads to these observations:
1. The software industry has no approach to reuse. It does have an approach to coding. If it had a systematic approach to reuse, it would have been widely mentioned in the article.
2. When companies try to achieve high reuse, they use home grown approaches. Some work, most don't.
3. Object oriented languages and OOAD are not reuse centric. They are merely a more organized approach to procedural programming, and offer productivity improvements because of that. Trying to "get high reuse out of OO" is a guarenteed mismatch.
4. For high reuse to occur, it needs proper infrastructure. For example, the internet took off when the infrastructure of TCP/IP, html and browsers became standards. For example, the Industrial Revolution occured only after interchangable parts and universal power became standards.
Certainly the last observation, reuse needs infrastructure to take off, is the key. What might that infrastructure be at the very minimum? Something allowing the equivalent of:
1. TCP/IP - A communication standard .
2. HTML and XML - A declarative, text based "what to do" standard.
3. Browsers - Standard visual tools.
4. "Interchangable parts" that allowed mass production and part industries.
5. "Universal power" - Steam and later electricity that powered individual machines.
These are well understood, widely accepted mechanisms. The fact that they made the internet and the Industrial Revolution possible is beyond question. How can these mechanisms be used to build the infrastructure needed for reuse to take off?
1. Communication standard - Use a "Circuit Based" approach like Messages between parts for all input and output.
2. A "what to do" standard - Use XML and DTD's (DK) for varying part reuse. All parts would be configured for reuse when initialized. Parts are DK Driven.
3. Standard visual tools - Use a System Tree of parts, a part DK editor, a Part Inspector, a Part Shop, etc for visual assembly of parts while the system is running. Any standard visual tool can handle any standard part. Developers can choose (or write) their favorite visual tools to work with their favorite parts, including their own parts. About all they can choose today with confidence is code editors.
4. Interchangable Parts - Achieve this by Circuit Based and DK Driven. A part's input Messages, output Messages and DK DTD define the part spec, making them interchangable.
5. Universal Power - Parts are "powered" by an underlying framework that the parts "plug into" for what they need. Once plugged in, the framework can "power" parts by doing lots of things for them, like Part Lifecycle Management, Message delivery, DK provision, access to the framework for dynamic behavior, etc. Because parts don't have to provide their own "power", they can be smaller, simpler, much more loosly coupled and much more reusable.
There you go. This is a simplistic takeoff on the article to show that high reuse is possible, even for short term work. To summarize my conclusions, the reason reuse doesn't work today is lack of reuse infrastructure, not because reuse itself can't work or is limited to the long term.
There are vast, uncharted reuse abstractions out there that are totally unimaginable to today's developers and managers. Their discovery is only a matter of time.
The whole thing reminds me of the days before 1492, when most knew the earth was flat. Or before Darwin's discovery of the abstraction of evolution. Or before the Cotton Gin, when plantation owners all knew that picking cotton had to be done by hand. Or before the Wright brothers flew in 1903, when most knew that man would never fly. Or before Einstein's discovery of the complex abstraction of relativity. Or before robot factories, when all factory managers knew that machines required operators.
In short, mass reuse efforts will continue to fail until mass reuse infrastructure appears.
Thanks, Tom! :-)