Sidney C. Bailin

Knowledge Evolution, Inc.

1050 17th St., NW, Suite 520, Washington DC 20036

Tel: (202)467-9588, fax: (202)467-9589

Email: sbailin@kevol.com

URL: http://www.kevol.com/

Like excrement (as the bumper sticker of old suggests), reuse occurs. Inevitably. Continually. Whether we foster it or not. As a culture of practice, we promulgate what works and discard what does not. Ideas catch on. The exponential marketing model of word-of-mouth recommendation applies to software techniques as well as to mildew remover.

The clearest sign, and most powerful form, of software reuse is that old reliable notion called the programming language. These things, which arrive on the scene in a big way every five or so years (and in a small way more frequently), are nothing but the (or a) community's collective expression of the desirability (usefulness, ubiquity) of certain software abstractions. The discovery of useful abstractions is the way in which domains mature and the software industry evolves. All this is a fundamental consequence of the nature of software as "soft," that is, easy (in some sense) to change, to enrich, to extend. Creeping features are like mildew; but with the regular application of appropriate cleanser (economic pressures), only the genetically most fit forms survive. And, conversely, only the most effective cleansers survive too.

This being the case, what exactly are we (the so-called reuse community) doing? Are we needed? Are we trying to take credit for something that happens anyway? Are our frustrations in making Reuse Happen just a reflection of the fact that you can't speed up Mother Nature (as she is expressed in human cognitive capacities)? Is that what we are trying to do - speed up the process? Make it more controllable? Predictable?

Why are we here?

I believe the answer to the above-posed questions is Yes, yes, yes, yes, and yes. And: we are here because, as human beings, we are incorrigible navel-contemplators (that being the old, now-discarded term for what is now called post-modernism).

We are not only tool-building animals. We are also story-tellers. We not only want to build a tool to rid our bathtubs of mildew, we want to create a myth that makes sense of the appearance of mildew in the first place, our distaste for it, and the success of our tool in vanquishing it. And then we want to apply this myth, this story, to guide us in future actions, including future tool-building. That way, maybe we can get rid of not only the mildew but the soap-scum as well.

One way to explain reuse is to note that programming languages represent major evolutionary steps. An abstraction has to become used and assimilated on an industry-wide scale before it makes its way into a programming language. But there are many smaller communities in which similar steps can occur. And they do. Hence domain-specific languages, for example. Hence company-wide toolkits. Hence the code generator produced, maintained, and used by a small, high-productivity skunkworks deep in the recesses of the company's Bombay office.

That is where we come in. Yes, reuse occurs. But for it to occur, it requires - well, a big push: something to overcome the inertia of current practice, in whatever state that may be. The repeated usage, the omnipresence of the abstraction must become so manifest that it cries out for codification. The benefits of having this reusable "thing" are so clear, to its potential (re-)users, that if they cannot make the business case (factoring in the cost of creating and maintaining the "thing") to their purse-string holders, they are likely to make an end-run around management and do it anyway.

Note, please, that the push in this scenario does not come from outside. It is not us, self-appointed guardians and saviors of the software industry, who make it happen through our advocacy of this or that method. The push comes from within the community that shares the abstraction. The caterpillar breaks out of its cocoon.

So why are we here?

We facilitate. We encourage. We enable. We try to get a community of software know-how to think of itself as just that: a community.

And how do we do that? Some of us - the techies; you know who you are - try to develop effective ways of articulating shared software knowledge. "Effective" means that, once so articulated, the knowledge can be applied. (That includes, of course, "found," "validated," and all the other gates to reusing something.)

Others of us - the beanies - try to develop ways of making the business case. "It's really worth the grunting effort to articulate the shared knowledge! Just look at this-here economic model." Or, perhaps it is not worth it in a particular case. We want to know that too.

Still others advocate ways of discovering the shared knowledge in the first place, and processes for capitalizing on it. This is where domain analysis, domain modeling, and domain engineering come in; also reuse processes, reuse maturity, and validation approaches: all the TMP (Theories, Methods, Processes) stuff, as Jim Neighbors has called it.

Although The LIBRA approach falls into the last category, it is qualitatively different from both domain modeling and process maturity methods. LIBRA is a set of techniques for fostering reuseful conversations - the kinds of interactions between developers (and other stakeholders) that tend to lead to the discovery of shared knowledge, or to consensus on how to articulate shared knowledge, or apply it. A basic tenet of LIBRA is that the real opportunities for reuse are found and/or created through the informal, fine-grained, detailed conversations that stakeholders have with each other in the course of doing their jobs. These conversations are too situation-specific and frequently ad hoc to make it into the process models or other maturity methods. They fly under the methodological rader. But they are where the action really is.

LIBRA consists of four mutually supporting tools: dramatic scenarios, belief mapping, system diagrams, and inquiry techniques. There is not enough space to describe these here; we (the creators of the method: myself, Mark Simos, Dick Creps, and Larry Levine) are writing a book on the method. But it is worth noting that the scenario tool, which is in a sense the center of the method, grew out of an experimental working group at WISR 7.

To summarize: reuse is not a "thing" that should be brought into a software organization. It is not a technology in itself, though it may make use of technologies in whose development our community plays a lead role. It is not even - as this author used to argue in his more innocent days - just an aspect of good software engineering. It is a cultural phenomenon that occurs when members of an organization decide to accrue software knowledge through a continual cycle of reflection, learning, articulation, and communication. We, the reuse community, help that happen.

I believe the theme that "reuse occurs" is somewhat like what Ruben Prieto-Diaz had in mind in his talk, "The End of Reuse," at the Third International Conference on Software Reuse (Prieto-Diaz92).

At the Fifth International Conference on Software Reuse, Paul Basset stated that the one remaining problem in software reuse is the problem of reuse culture (Bassett98). His emphasis was on overcoming the Not Invented Here (NIH) phenomenon.

A similar view was stated several years ago by Brad Cox (Cox90), who compared the current state of software construction to the early days of gun manufacture. Cox argued that, as in that other industry, a component-assembly based approach will eventually prevail by virtue of economic selection.

This author takes a different (though not diametrically opposed) view. I agree with Bassett that the problem is one of culture, although LIBRA views NIH as only one among many sources of resistance to reuse. I also agree with Bassett and Cox that a component-based approach to software development is desirable. I disagree with both of these authors, however, about the root of the problem. Basset maintains the widely held view that the problem is one of immaturity: The software industry needs to start viewing itself as a form of engineering, subject to and enabled by the same levels of discipline as other engineering fields.

In (Bailin97) I argued that this view is over-simplistic. Fred Brooks observed that software has certain unique properties both as technology and as a cultural medium (Brooks87). In particular, software serves in our culture as a complexity sink for the systems we build. We stress software development with unprecedented and volatile requirements, and then we wonder why it is so difficult to manage. Our stressing software like this is not an accident or aberration. It is, rather, a consequence of software's distinctive properties, such as its weightlessness and apparent adaptability.

Cox fully acknowledges the differences between software and other forms of engineering. In arguing for a software industrial revolution, he recognized that the paradigm shift would have to be as much about disciplined requirements specification as about design and implementation. In a more recent paper, he argues for a new economic paradigm that recognizes the difference between software and material assets, and replaces "payment for bits" with "payment for function." He believes that this will provide the necessary incentives for component-based software development.

Cox and I agree that the road to manageable software development is not to try to make software something that it is not - something less than it is - but to face its uniqueness head-on. Cox faces this uniqueness by proposing a new economic model. The LIBRA approach, which is not inconsistent with Cox's but has a different emphasis, is to view software development less as a form of automation and more as a form of knowledge creation. Software reuse then becomes primarily a form of knowledge sharing.

The LIBRA approach itself builds on general concepts and techniques in the field of organizational learning. It is most directly influenced by the work of Peter Senge (Senge90) and Chris Argyris (Argyris92). One of LIBRA's creators (Larry Levine) is a specialist in organizational development, and he brought to the method extensive knowledge of current work in that field.

Sidney C. Bailin is founder and President of Knowledge Evolution, Inc. (KEI). Prior to forming KEI, he was a Vice President of Engineering at Computer Technology Associates, where for 12 years he played a leading role in that company's software technology program. His twenty years of software experience has ranged from the development of production real-time communications systems to R&D in advanced software productivity tools. He has been active in the reuse community for 12 years. WISR actually grew out of the Tools and Methodologies working group that he co-chaired at the 1987 Minnowbrook Workshop on Reuse.