Contents |
|
Reuse and Staying in Business
There is a saying that goes “It’s hard to drain the swamp when you’re up to your butt in alligators.” A corollary might be “It’s hard to think long-term when you’re fighting to make next week’s payroll.” A reusable component can cost three to five times more to develop than conventional software because the reusable component cannot make simplifying assumptions about its environment. At the 1998 conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) in Vancouver, Luke Hohmann offered a wonderful example to illustrate this point. Consider a game program that requires a six-sided die. As an old-time C/C++ programmer, I can write that in one line, call rand(), do modulo arithmetic on the result, and return an integer between 1 and 6. No problem—10 minutes, tops!
Now, what if I want this to be a reusable component? First, I can’t assume the die has only six faces, so I have to design the Dice class to take a parameter that tells it the number of faces. Pretty simple, but a bit more work than my simple one-liner.
What value should each face of the die have? Many games have dice that turn up messages, so I probably want to construct the Dice class to select an entry from a pre-defined list of values. This is starting to get complicated. Then there is the issue of error handling. Because the Dice class cannot make any assumptions about its environment, it will have to use some kind of exception handling mechanism to report problems. Clearly, this is going to take me a lot longer than my simple one-liner to design, code, and test. Finally, I’m going to have to write a programmer guide that explains how to use the Dice class.
The economic justification for spending this extra effort to design the Dice class is that your development organization can amortize the cost of the reusable component over several generations of product or over several different products. This means taking a long-term view and regarding the extra time and effort creating the reusable Dice class as an investment that will generate savings for future systems.
Long-term thinking and vision is often hard to come by in an industry where market windows for products may be open for fewer than six months and the first one to market takes all. This isn’t due to narrow vision and greed on the part of management; it is simply the economic reality. In a small startup, people may have mortgaged their homes to finance the company. They aren’t thinking about how the company will compete in the long term—they’re hoping they will have a product to sell before the money runs out.
A company working to create reusable components for its product will be beaten to the marketplace. It may have a long-term economic advantage over its competitors, but only if it survives for the long term. If the faster moving, handcraft company gets to the marketplace first, it will establish marketshare and may be able to crowd the first organization out.
Few and Far Between
There are, however, counterexamples to this software development model; some organizations are currently achieving very high levels of reuse. An excellent example is the Software Engineering Laboratory (SEL) at NASA Goddard, which routinely achieves an astounding 75% or higher reuse level (see “Evolving the Reuse Process at the Flight Dynamics Division (FDD) Goddard Space Flight Center” by S. Condon et al. The article is available from NASA/Goddard’s web site at http://sel.gsfc.nasa.gov/doc-st/tech-st/sew21/reuse-pr/sew21gss).
This level of reuse is being achieved in the fairly specialized problem domain of spacecraft flight dynamics. The SEL adopted a domain analysis approach, carefully studying and modeling to create the reusable components. The process of domain analysis is similar to requirements analysis; the domain analyst reviews the requirements for past, present, and, when possible, future space missions. The specifications for reusable components are derived from this information. Construction of applications for a specific mission then becomes more configuring components from a reusable asset library than new development. The key aspect of domain analysis is that requirements extend beyond a single project.
The results speak for themselves. Prior to the construction of the reusable asset library, it took 58,000 hours to develop and test an application for a typical flight dynamics division mission. A recent flight dynamics application configured from the reusable asset library took just a tenth of the effort.
Of course, this tremendous improvement in productivity did not come free. Construction of the asset library required 36,000 hours of domain analysis and 40,000 hours to design and implement the components. They started designing the reusable asset library in 1992, and configured the first application from the library in 1995. The SEL estimates that it will have recouped the library development costs by its fourth mission.
NASA has, as well it should, the luxury of being able to take a long-term view. It is hard to imagine a typical software product company having the economic resources to perform a domain analysis. Can you visualize your development organization being able to divert its best developers from current production to create reusable assets, no matter what the long-term benefits are? The initial investment required to develop a reusable library or framework is an economic barrier to the adoption of a systematic reuse program. But hold on a minute! Why am I talking about building your own reusable components? After all, very few hardware vendors make their own chips. Why not just buy your reusable components off the shelf?
________________________________________________________