Why Doesn't the Reuse Community Talk About Reusable Software? Ralph E. Johnson University of Illinois Department of Computer Science Tel: (217)244-0093 Email: johnson@cs.uiuc.edu WWW: http://st-www.cs.uiuc.edu/users/johnson/ Abstract The reuse community spends too much time talking about reusable software in general and too little time talking about reusable software in particular. We need to study and compare the designs of particular reusable systems so that we can improve them (and so make reuse more valuable) and so that we can learn the principles of reuse. Workshop Goals: Learning; Finding kindred spirits. Working Groups: Domain analysis/engineering; Reuse and OOmethods and technology; Reuse handbook; Reusable architectures for business software. 1 Background I've been working with OO technology for 10 years, trying to see how objects change the way we develop software, especially how it impacts software reuse. I quickly noticed that reuse of code and small components was not what was important, but instead reuse of design in the form of larger components called frameworks. A framework is a reusable design expressed as a set of abstract classes and the way that instances of these classes interact. In one sense, the most important thing about a framework is the interfaces that it defines. Because a framework is made up of classes that can be represented in programming languages, it is reusable code. But it tells you how to decompose your program into objects, and in that sense is a design. Moreover, most of the code reuse comes not from inheriting from the abstract classes but from reusing concrete classes from a class library. The concrete classes reuse the standard interfaces defined by the framework, so they can be mixed and matched. Most of the reuse comes from being able to mix and match components, not from being able to define a new component using inheritance. I've worked on a number of frameworks, including the frameworks that come with Smalltalk-80 (VisualWorks), a framework for drawing editors called HotDraw, a framework for operating systems called Choices, a framework for code optimization and code generation, a framework for music synthesis,and a framework for accounting. While none of them have had large numbers of users (HotDraw probably has the most users, and that is probably 50-100), most of them have had a few users outside of my research group. Recently I have been working on documenting the software patterns that expert designers use. Not surprisingly, I have focused on the patterns that OO designers use to make software more reusable. 2 Position One of the distinguishing characteristics of computer people is the tendency to go meta at the slightest provocation. Instead of writing programs, we want to invent programming languages. Instead of inventing programming languages, we want to create systems for specifying programming languages. Instead of analyzing domains, we want to make methods for domain analysis. And instead of writing reusable software, or reusing software, we want to write about the principles of software reuse. There are many good reasons for this tendency, since a good theory makes it a lot easier to solve particular instances of the problem. But if you try to build a theory without having enough experience with the problem,you are unlikely to find a good solution. Moreover, most of the time spent building reusable software is on issues that are particular to the problem that the software is supposed to solve, not on generic reusability issues. We are in danger of attacking secondary problems and ignoring the most important ones. The software community has developed standard architectures for some kinds of software, such as compilers, operating systems, and user interfaces. Not surprisingly, these are the kinds of software for which we have the best reusable software; parser generators and table-driven code generators for compilers, and GUI frameworks and screen painters for user interfaces. But there are a lot more people building accounting systems or manufacturing systems than building compilers, and we have tended to ignore applications software, even though that is the most financially important kind. Although there are reuse success stories among this kind of software, I believe we are only seeing a fraction of what is possible. Whenever a standard architecture has developed in the past, it has been developed in a context of a community that can bring many perspectives to bear on it. The practitioners are from companies that are trying to build commercial software. Researchers are investigating narrow problems within the domain of the architecture. Textbook writers are trying to organize and systematize the material. Why hasn't this happened with accounting software or manufacturing software? One possible reason is that companies are afraid of losing trade secrets. But that reason didn't keep the system software venders from participating in conferences on compilers or operating systems. I think a more important reason is that reseachers have ignored these topics. If the researchers were holding exciting conferences on these topics,practitioners would come to find out what was going on, and they would figure out how to make the researchers want to talk to them. But without all the members of the community, it is much harder to make progress. What can practitioners do to attract the attention of researchers? One obvious technique is to support their research financially. Another is to helpconferences on the domain of interest get off the ground. When organizations have their own research department, practitioners can try to get some of the researchers interested in their problems. Regardless of which methods are used, changing other people's behavior is always hard. Is it worth trying to organize groups of people working on particular kinds of software? I think this is the only way to make good reusable designs. To be reusable,software has to be reused in many contexts, and there are very few companies that have the resources to do it. It can be difficult breaking though the parochialism that effects so many companies, but I think it is important if we are going to achieve our goals for reuse. 3 Biography Ralph Johnson is on the faculty of the Department of Computer Science at the University of Illinois. He was program chair of OOPSLA'93, and is a coathor of "Design Patterns: Elements of Reusable Object-Oriented Software" with Erich Gamma, Richard Helm and John Vlissides.