Paul Bassett speaks about his book, the state of software reuse today, and what he's learned about frame technology since he invented it over 20 years ago.

What's holding most organizations back from achieving high levels of reuse?

First I want to stress that high is a relative term. For me 85% reuse is normal, not high. At that level, people enjoy 70% reductions in time-to-market and 84% reductions in development cost. And getting such results is not hard. I call this "project" level reuse. There are two higher levels, systemic and cultural reuse. These levels imply 90% and 95% reuse respectively. Getting to these levels requires changing the way the organization works, something that is both hard to do, and somewhat threatening to those involved. By the way, don't think that going from 90% to 95% reuse is a marginal improvement. Turn it upside down and you are going from 10% of the work to 5%; you just doubled your productivity! Cultural reuse is as far beyond project-reuse as project-reuse is beyond the industry average (70% less time and 84% less cost).

You strongly believe that technology is only a small part of the reuse problem. Why?

We are dealing with a new way to think about software development. Technology does not do our thinking for us. Not only do practitioners need to change their thinking, but so do managers; moreover the corporate learning curve involves changing the infrastructure and the culture of the organization. So there are four categories of thinking, each one of which can facilitate or impede reuse. Technology is a critical enabler, but it is far from sufficient to get to reuse Nirvana. Don't get me wrong. Only practitioner thinking needs to change in order to get the kind of improvements cited by metrics auditor QSM. But to get beyond project reuse, technology is not the issue. No pain no gain.

You say in your book that people confuse "use" with "reuse". What do you mean by that?

Every time you turn on your stereo, you don't think, "Wow, I'm reusing my stereo!" Are you using your phone every time you get or make a call? Yes, of course. So why, everytime we call a subroutine or send a message to an object, do we want to think of that as reuse? Multiple use-as-is is a defining characteristic of use, but only a trivial form of reuse. For hard problems such as efficiency, maintainability, context sensitivity, portability, adaptability, and so forth, use-as-is has no horsepower. 

So, what is reuse? Suppose your phone could be transformed into cell phone, a roam phone, a pager, or a microphone. This sounds bizarre because modifying physical things is literally hard. But modifying software is both easy and natural. Thus in software engineering, reuse is the process of adapting generalized components to multiple uses. 

Hiding behind the use/reuse confusion is a deeper failure to perceive the duality between run time and construction time. Use belongs to the former, reuse to the latter. They are dual concepts. Usability concerns itself with functionality, efficiency, and ease-of-use, and with the tradeoffs to be made among them. Reusability concerns itself with the dual properties of usability, generality, and adaptability (ease-of-reuse) and their tradeoffs. Once this duality is grasped, it opens the door to highly usable systems built from highly reusable components. The classic tradeoffs between performance (efficiency) and flexibility (adaptability) need no longer be made. You can have both because they can be optimized independently, thanks to duality. 

Why did you subtitle the book, "Lessons from the Real World"?

My subtitle is apt for three reasons. First, I want to stress that the book's extraordinary claims are backed by extraordinary real world evidence, in the form of the report from the independent auditor, QSM. Second, I have over 15 years worth of scars on my back, trying to apply adaptive reuse to hard problems, and some of what I have learned is distilled in the book's theory and case studies. Third, the reuse-based software development process, called Iterative Design Refinement, vitally depends on ongoing feedback from key stakeholders—a lesson from the real world, if you like, about how closely the current version of a system being (re)developed matches the current need. 

What problems were you trying to solve when you invented frame technology?

I had two frustrations. I had my own small business, Sigmatics Computer Corporation, where I sold turnkey hardware and software systems to other small businesses. I would no sooner deliver a system to one customer than another would want a system that, on the surface, looked different, but scratch the surface and there were huge similarities. Trouble was, in less time than needed to extract the common elements and recustomize them, I could write another system from scratch. 

My other frustration centered on code generation. In an effort to improve productivity, I wrote a report program generator and another for screens. Invariably there were small tweeks to the generated code that were outside the scope of the generators. The problem was that such tweaks meant I could not modify screen and report layouts without clobbering the tweaks. This is a well known problem with generators; most people simply give up on regeneration and continue to patch the generated code. But I wrote the darn things and I was determined to keep using them. So there I was editing my tweaks over and over again, and cursing the fact that a machine could be doing it but wasn't. 

Having invented frames to solve these problems, I discovered they could do lots of other neat things, and it was to take me over a decade to understand why. That's how I learned about the fascinating issues of adaptive reuse. 

What exactly is a frame?

A frame is an adaptable component of information expressed in any language, but usually a programming language. Programs, subroutines, objects—any kind of information module—can be assembled automatically from one or more frames, organized as in a parts explosion diagram. 

Frames embody adaptive reuse. That is, each frame can adapt any of its component frames, and, in turn, be a component that is adapted by other frames. By adapt I mean a frame has commands that add, delete, select, modify, and iterate the default properties of other frames, if necessary, right down to individual symbols. Because frames adapt general patterns into specific instances, a small number of frames is sufficient to build a large number of modules. 

Isn't this just another flavour of object-orientation?

Not really. The current OO paradigm is strong at run-time but weak at construction-time. By that I mean collections of interacting objects (encapsulated, loosely coupled agents) are a better way to model the real world than the monolithic systems of the past. This paradigm enhances the usability of software, but says nothing about how it should be designed and built. That is where adaptive reuse comes in. 

Before explaining how frames complement OO's strength, I need to talk about OO's Achilles' heel—inheritance. Inheritance organizes domains into hierarchies of classes, subclasses being more detailed and super-classes more abstract. In my book I describe at least half a dozen problems with inheritance. Here is a fairly fundamental one. 

Inheritance cannot simultaneously model abstractions and part relationships-what is a component of what. Instead, composite objects must be modeled by "aggregation"—calls or messages to and from component objects at run time. But part relationships are structural invariants, not the sort of thing that changes during execution. Is your head dynamically linked to your body? Is your head even an encapsulated object, capable of independent behavior? The consequences of such inappropriate domain modeling are quite serious, including too many tiny classes, too little reuse per class, and much unnecessary complexity. 

Frames can avoid the problems of inheritance because they rely on active adaptation rather than passive inheritance. (1) Frames can model a domain's natural component boundaries. Some frames will be large, others tiny, and anything in between. Domains requiring several thousand classes can be modeled by 100-200 frames. (2) Abstractions are localized in individual frames, rather than being lost among a sea of look-alike polymorphs. (3) Encapsulation is just what you need at run time, and the last thing you need at construction time. Imagine buying a washing machine and finding all the parts are welded together. So, to answer your question, frames are not just another flavor of OO. They complement the strength of the OO paradigm. Frames allow you to practice an advanced form of OO, and do it in any language. 

There are a lot of ways to achieve reuse. Why frames?

Frames are just one way to accomplish adaptive reuse, one that has been found to work. The world is full of theories for software development, many of which are plausible and have merit. Trouble is, their advocates rely more on faith and opinion than hard evidence. That's why our industry suffers from the fad-of-the-year syndrome, and why there are so many religious wars. 

When I first conceived of frames, the idea seemed so simple I thought it must have already been tried and rejected as ineffective. Since then it has become clear that, while many ideas are similar to frames (macros for example), each suffers from something or other that explains why they don't deliver the benefits of adaptive reuse. When someone can eclipse frames with the kind of hard evidence that QSM has published, I shall be among the first to applaud! 

How are people using frames?

The biggest trend today is towards frameworks—construction architectures. It is one thing to have an architecture that defines the way executables interact—e.g., client server. It is quite another to have a construction architecture that minimizes the number of reusable components and maximizes system adaptability. Companies are finding that frames are ideal for embedding such architectural models. A construction architecture gives you high levels of design reusability and a solid, predictable, mental framework within which to work. This is key to achieving very high productivity without sacrificing adaptability. 

Frameworks are also a form of protection. They keep customer-specific functionality in frames separate from functionality which vendors may supply to everyone in a given industry, for example, banking. That enables the vendor to enhance its standard banking architecture without forcing you to rewrite your customizations. And you can quickly see how to exploit their enhancements because frames make them completely visible. 

Another trend is to write templates, high-level frames that sit on top of frameworks. The kinds of solutions that are typically captured in templates are model applications, standard methods of integrating with legacy applications and data, and access to external sources like third-party tools and other applications. 

If frame technology is so great, why isn't everyone using it?

Adaptive reuse involves far more than technology. It's a new way to think about software development, from both technical and managerial perspectives. The cliché that comes to mind here is "paradigm shift." According to Wayne Burkan, who has written extensively on the subject, a true paradigm shift requires a generation to get from invention to convention. For most of that 20 to 25 years the new way of thinking and working is largely invisible. At first it is ignored. Then, because it threatens the status quo, it enters the denial stage. After denial comes awareness, followed by comprehension, and finally common practice. 

Horseless carriages took a generation to become commonplace cars. Software also took about the same time to become ubiquitous. But software reuse has been a thorny issue for two generations, largely because the notion of parts adapting parts runs counter to our everyday experience with physical parts. Until recently, adaptive reuse has been in denial; its productivity levels were seen as literally incredible, which is why I invited QSM to audit the claims. With the publication of this book, 18 years after the invention of frame technology, I'm expecting adaptive reuse to enter the "awareness" stage. 

Are frames complicated to learn and understand?

As I say in my preface, learning the rules of chess takes only a few minutes. Playing master level chess takes a wee bit longer. So it is with frames. The basic ideas are dead simple; applying them properly on single projects is not very hard. Getting to systemic reuse is harder, because the ideas are in conflict with the status quo. And there is even a level beyond that, kind of the international grand master level. I call it cultural reuse, but most would think of it as reuse Nirvana. 

What do you think will be the state of software engineering in 10 years? Will we be doing a lot of reuse?

If I'm right about adaptive reuse being a paradigm shift, in 10 years we should be past the point where it becomes mainstream. This implies that software engineering will see adaptive components as fundamental to the discipline. Researchers will be refining the theory and teaching it to their students. Practitioners will be routinely achieving tenfold improvements in productivity over today's norms. Adaptable packages will be easily customized and evolved without vendors and customers tripping over each other's changes. In-house software organizations will be anticipating their companies' business in order to give themselves short times-to-market. Standards setters will be trying to define a standard mechanism to maximize the interchangeability of frameworks. We will all be building systems of far higher complexity than most can contemplate today. 

No one will be talking about reuse. Like all other mature engineering disciplines, reuse will be so fundamental to everyone's thinking and working that it will be taken completely for granted. Adaptive components and frameworks yes, reuse no.