Production Models Drive Reuse Readiness

Eric Price

Lexis-Nexis

Miamisburg, OH 45342

Tel: (937) 865-6800, fax: (937) 865-1655

Email: ericp@lexis-nexis.com

URL: http://www.donet.com/~eprice

Reuse programs have high failure rates. When they succeed, they are often difficult to replicate throughout the corporation or at other corporations. Reliably replicating successful reuse programs is a primary concern for reuse practitioners and their employers. This situation may be a result from failure to identify both the prerequisites to successful reuse and the organizational culture issues that drive the organization's readiness to institutionalize software reuse.

Determining an organization's production model and implementing a compatible reuse methodology is critical to institutionalizing reuse.

Production models are deeply held views about the nature of work in the industrial age. They can be so strong that they are culturally ingrained as part of national or regional character. If unidentified, they can undermine corporate change efforts: A plausible explanation for the large number of reengineering failures is the unstated assumption that reengineering would implicitly shift an organization's production model. Because of the cultural hold (i.e. staying power) of production models, an explicit commitment by senior management--and follow through--is likely required to effect the change of an organization's production model.

In discussing internal conflicts which contributed to IBM's loss of market share, [Ferguson94] discusses 6 production models. Those models, along with a seventh emerging model, are discussed below with the model's likely impact on software reuse.

In American mass production, companies can be slow to adapt due to entrenched functional silos based in the division of labor and the belief that "all possible brain work should be removed from the shop floor" [Creech94]. In this model, coders might reuse simple libraries (such as system libraries) but would have little impact on design, and no sense of ownership of higher-level artifacts.

With German engineering, sophisticated products are built by workers whose skills are developed through a rigorous system of apprenticeship. In Japanese lean production, adaptable, multifunctional teams are trained and empowered so the need for bureaucratic oversight is reduced. Both these models stress the professionalism of the worker, and would be more likely than American mass production to support in-house development of reusable components.

In the monolithic model, large capital investments are possible by rolling profits into successive generations of the product. This production model seems particularly well suited to reuse methodologies based on product lines. AT&T, IBM, Motorola, and other communications companies provide examples of the product-line reuse methodology succeeding within the monolithic production model.

The megaproject model is characterized by complex products with high cost and low production volumes, coordinated effort of many companies and often government funding. Reuse within this model can be hampered by funding or legal complications.

A recent production model is the Silicon Valley model for products of high intellectual content, typically software and semiconductors. In this model, companies concentrate on developing core expertise and partnerships with external suppliers. It is within this model that one finds a growing software component industry such as envisioned by [McIlroy69].

An emerging production model is the bazaar [Raymond97]. This model combines the features of informal apprenticeships, elimination of bureaucracy, customer focus, and global resources. It is applicable primarily to intellectual property, where initial investment (i.e. non-recurring engineering) is high, but per-unit production costs are negligible. The initial investment is through volunteer (e.g. apprentice) work, or taken as a business loss. Return (if any) on the initial investment is through software support agreements or increased productivity (if the developers are among the project's customers).

Two groups of reports were reviewed for anecdotal evidence linking production model and reuse program success. The first includes reports from the Software Engineering Institute product line architecture workshops, [Bass98] and [Bergey98]. This group is representative of the monolithic and megaproject models. The second source consists of papers describing the culture of Open Source Software development, [Raymond97], [Raymond98] and [Dougherty97]. This group focuses on the bazaar and Silicon Valley models.

Because SEI work is strongly biased toward organizations which use the monolithic and megaproject production models, the positive results of their work on software reuse in product lines provides implicit recognition of the relevance of production model to reuse methodology selection. The SEI documents suggest that their authors are systematically assessing reuse within monolithic production models with the intent of adapting these reuse methodologies to the megaproject model.

As the production model hypothesis suggests, the SEI found that co-development of components was unlikely to occur among its workshop participants, although they did acknowledge this practice (which is typical of the Silicon Valley and bazaar models) was "an effective means to achieve optimum performance."

In addition, the SEI has explicitly stated the correlation of Capability Maturity Model (CMM) level to successful product-line reuse:

An organization must be at CMM level 2, at least with respect to configuration management, by the time the first product in a product line is shipped.

Moreover, not just the CMM level, but specific structural advice is given with respect to the organization of CM activities:

The "emphatic advice" of workshop participants was that the details of configuration management be decided by producers, "and not 'some detached Tools and Methods Department' whose stake in the game is once removed at best."

This observation is an implicit recognition that the functional silos common in American mass production (e.g. separate process, tools, and metrics groups) impose a barrier to successful reuse. The tenet that process is owned by the people who execute it is fundamental to the Japanese lean production and the bazaar models. In addition, it has been successfully adapted to the monolithic and Silicon Valley models, often as part of "Total Quality Management" efforts.

The SEI also noted that business metrics (rather than process metrics of CMM level 4) were important in guiding reuse.

The bazaar model has been particularly effective for open source software development. Packages such as linux, apache, perl, majordomo, sendmail, bind, as well as high quality development tools (gcc, emacs, flex, etc.) are developed, maintained and enhanced as open source.

These tools represent both reuse in the small and reuse in the large. Examples of reuse in the small include emacs and perl (which provide the custom languages for creation of reusable libraries and channels for their distribution) and flex (which provides generative reuse).

Other open source software provide frameworks for interprocess communication and networking (linux, bind and sendmail) which allow programs such as ghostview to be coupled with Web browsers and servers (mosaic, lynx and apache) to enable the rapid initial growth of the World Wide Web. Programs such as TeX and gimp aid creation of Web documentation and images. Since most of these packages were never intended as Web components, the argument could be advanced that the Web constitutes the world's most successful example of software reuse in the large.

In addition, vendors such as HP, IBM, and Digital participate in organizations such as The Open Group, which provide common standards, reference implementations and validation suites. Such organizations and reusable artifacts are the mechanisms through which vendors collaborate in a Silicon Valley model of production. This legacy of software reuse can be traced back to the portable C compiler, which ensured software on UNIX systems could be ported to other UNIX systems by providing a compiler which was itself portable-thus providing a common front end on disparate systems which constituted a de facto language standard.

These collaborative mechanisms allow both the Silicon Valley and Bazaar production models to achieve the "optimum performance" associated with component co-development. The bazaar model has additional strengths that shape its reuse methodologies. Participants are drawn from a global talent pool that few companies can match. They have specific talents for knowing what to rewrite and what to reuse; avoiding design flaws, code bugs, and development dead-ends; and attracting peer co-developers [Raymond97].

Can corporate reuse programs achieve the optimum performance of the bazaar model? Perhaps not. As noted by [Brooks95]:

Most organizations spend considerable effort in finding and cultivating the management prospects; I know of none that spends equal effort in finding and developing the great designers upon whom the technical excellence of the product will ultimately depend.

Perhaps the design talent required for the bazaar model is globally dispersed because organizations choose not to value and cultivate it!

In 1990, Bertrand Meyer announced that new technologies heralded "a shift to a 'new culture' whose emphasis is not on projects but instead on components." Are organizations ready for a Silicon Valley model of software production, using key components supplied by third parties? History suggests not.

Other authors have chronicled the difficulties of reuse adoption. Prieto-Díaz asked, "Why is reuse not delivering?" [Prieto-Díaz91]. Later, he observed, "A fundamental flaw in [reuse maturity] models is that they are the product of inducing what would be the most logical set of levels. These maturity models are not based on experience" [Prieto-Díaz93]. He then proposes a faceted classification scheme for an organization's reuse characteristics. In contrast, this paper presents one facet (i.e. production model) of an organization's culture. Other relevant cultural facets are implicit in [Price97].

Organizational culture and people issues are mentioned in the literature but taxonomies for individual facets have been rare. Nonetheless, the importance of these issues has been acknowledged. For example, in business engineering supported by high levels of reuse "50-70 percent of business engineering attempts fail, largely due to insufficient attention to the 'soft' factors." [Jacobson97]

One valuable taxonomy of development personnel notes that some organizations have an over-abundance of programmers who "do not know how to estimate savings in reusing a piece of software let alone how long it will take to develop and test a piece of software from scratch" [Tracz95]. Once an issue that undermines reuse is identified in a taxonomy, other work can address how the issue might best be addressed. For example, a contributor to the under-appreciation of reusefulness noted by Tracz might be functional fixedness, which is addressed in [Latour97].

An important resource for identifying cultural facets is the People Capability and Maturity Model (P-CMM)[Curtis95]. The P-CMM's goals for training and work environment could well be prerequisites for successfully adopting a reuse methodology.

Until appropriate reuse methodologies can be reliably selected through accurate diagnosis of an organization's reuse readiness, observers will continue to bemoan the "hidden costs of code reuse" [Radding98] which hasn't delivered "despite more than 15 years of trying" [Orenstein98].

[Bass98] Bass, Len, Gary Chastek, Paul Clements, Linda Northrop, Dennis Smith and James Withey, Second Product Line Practice Workshop Report, Software Engineering Institute, April, 1998.

[Bergey98] Bergey, John, Paul Clements, Sholom Cohen, Pat Donohoe, Larry Jones, Bob Krut, Linda Northrop, Scott Tilley, Dennis Smith and James Withey, DoD Product Line Practice Workshop Report, Software Engineering Institute, May, 1998.

[Brooks95] Brooks, F. P., The Mythical Man Month, Addison-Wesley, 1995.

[Curtis95] Curtis, Bill, William Hefley and Sally Miller, People Capability Maturity Model, Software Engineering Institute, 1995.

[Dougherty97] Dougherty, Doug, "Information Wants to be Valuable," Web Review, August 29, 1997.

[Ferguson94] Ferguson, Charles and Charles Morris, Computer Wars: The Fall of IBM and the Future of Global Technology, Times Books, 1994.

[Jacobson97] Jacobson, Ivar, Martin Griss, and Patrik Jonson, Software Reuse: Architecture, Process and Organization for Business Success, Addison-Wesley, 1997.

[Latour97] Latour, Larry, "The Need for a Cognitive Viewpoint on Software Component Understanding," Eight Annual Workshop on Software Reuse, Columbus, OH, 23-26 March 1997.

[McIlroy69] McIlroy, M. "Mass Produced Software Components," Proceedings of NATO Conference on Software Engineering, New York, New York, 1969, pp. 88-98.

[Meyer90] Meyer, Bertrand, "Lessons from the Design of the Eiffel Libraries: Tools for the New Culture," Communications of the ACM, Vol. 3, No. 9, 1990.

[Orenstein98] Orenstein, David, "Code Reuse: Reality Doesn't Match Promise," Computerworld, August 24, 1998, pp. 8.

[Price97] Price, Eric, "Organizational Culture and Behavioral Issues Affecting Software Reuse," Eight Annual Workshop on Software Reuse, Columbus, OH, 23-26 March 1997.

[Prieto-Díaz93] Prieto-Díaz, R. "Issues and Experience in Software Reuse," American Programmer, Vol. 6, No. 8, pp. 10-18, August, 1993.

[Prieto-Díaz91] Prieto-Díaz, R., "Making Software Reuse Work: An Implementation Model," ACM SIGSoft Software Engineering Notes, Vol. 16, No. 3, July 1991.

[Radding98] Radding, Alan, "Hidden Costs of Code Reuse," Information Week, November 9, 1998.

[Raymond97] Raymond, Eric, "The Cathedral and the Bazaar," Internationaler Linux-Kongreß, Würzburg, Germany, 21-23 May 1997.

[Raymond98] Raymond, Eric, "Homesteading in the Noosphere," April, 1998.

[Tracz95] Tracz, Will, Confessions of a Used Program Salesman, Addison-Wesley, 1995.

Eric is a senior software engineer at Lexis-Nexis where he provides support and mentoring for reusable C++ software, including HP's OODCE client-server framework. Most recently, he has tuned vendor-supplied components (third party source code) to provide the scalability of the distributed infrastructure that hosts the company's popular Web products.

He holds an MS in mathematics from the University of Illinois and previously worked in technology transfer as the liaison from NCR to the Microelectronics and Computer Technology Corporation.