Book Foreword by Ed Yourdon

What began as a casual dinner conversation nearly ten years ago has finally emerged as Paul Bassett’s important book on software reuse. Paul and I and the publisher have been somewhat frustrated by the slow gestation of the ideas you’re about to read. Perhaps it’s for the best: I’m not sure the world was really ready for a serious, in-depth treatment of the concept of software reuse back in 1987.

Today, with the industry buzzing about components and objects and applets, perhaps we are ready. There is an increasing demand from business executives for higher levels of productivity, dramatically shorter development schedules, and higher levels of quality.

More and more organizations are concluding that reuse is not just a “Boy Scout virtue” like loyalty, bravery, and thrift—but a serious engineering approach yielding enormous practical benefits.

Of course, every software engineer has heard of reuse—and many will claim they’ve attempted it, in one form or another. But as Bassett describes it, the reuse that actually occurs in the typical organization is “ad hoc”, or accidental. Indeed, most organizations are entirely unaware of the level of reuse that occurs within their organization, as I’ve been able to confirm from numerous informal surveys around the world. Bassett optimistically suggests that the level of “ad hoc” reuse can vary from 0% to 40%; in most of the metrics investigations I’ve seen of such organizations, the actual number is closer to 20%.

One reason for the increased level of reuse that we’ve begun to see throughout development organizations is the appearance of a number of application development environments like Smalltalk, Delphi, Visual C++, and Visual Basic—which come with a rich library of reusable components. Indeed, it’s so rich that most developers don’t have a chance of learning or using all of the vendor-supplied components, but that’s a different story. Bassett refers to this form of reuse as “latent reuse.” While it has indeed had a positive impact on productivity, especially in the building of fancy GUI windows that our users love so dearly, the vendor-supplied components are relatively low-level “grains of sand.” With little or no connection to the application domain in which the developers are immersed.

The next level of sophistication involves intra-project reuse, which typically results in 80-90% reuse; and this is typically the level that “ordinary” advocates of reuse achieve. What’s significant about Bassett’s work — and the material in this book — is the emphasis on achieving a higher level of reuse known as “systemic” and a level beyond that known as “cultural reuse.” In organizations practicing the most advanced forms of reuse, reuse is typically at the 95-99% level; productivity levels are almost two orders of magnitude above the “ad hoc” reuse organizations.

To make this work requires some technology, and some significant organizational changes. The technology introduced by Bassett is the technology of frames. A completely new concept to most software engineers, it may cause a certain degree of bewilderment on the part of programmers who thought object-oriented programming provided all the mechanisms we would ever need to support reuse. But as you’ll learn in Chapters 12 and 13, there are a number of subtle problems with conventional OO methods and tools. On the other hand, Bassett reassures us that, “the good news is you can practice an advanced form of OO using frame technology, and do it with any 3GL.”

That’s an incredible statement — you can practice an advanced form of OO, and achieve astounding levels of reuse — without abandoning COBOL and jumping into what many business-oriented application programmers regard as the alien and unpleasant world of C++, Smalltalk, or (to be au courant) Java. Indeed, such a statement would seem so outrageous and politically incorrect (for today’s computer community is highly politicized, as evidenced by the ongoing debates over languages and methodologies!), were it not for the convincing case studies and examples Bassett describes in this book.

The technological aspects of frame technology are indeed important. But for most organizations, the management issues will spell the difference between success and failure. At the very least, these organizational and cultural issues will determine whether the organization remains rooted at the ad hoc level of reuse or has a reasonable hope of reaching the systemic or cultural level of reuse that Bassett describes.

I’ve done a reasonable amount of consulting work in this area, and I know that the organizational changes required to support systematic forms of reuse are difficult to accomplish; but it’s also evident, from the discussion throughout “Framing Software Reuse” that Bassett has thought longer and deeper and harder about the issues than I have. The fact that he has explained the issues cogently, and often quite eloquently, won’t necessarily be enough to accomplish miracles in your own organization. But it’s an important start.

Indeed, that’s what Bassett’s book really represents: an important start, for most of us, on the road to “serious” reuse. Most of us are rank amateurs when it comes to reuse. It’s analogous in many ways to the amateur tennis players who watch Wimbledon matches on television and then wonder why they can’t play as well as Pete Sampras or Steffi Graf. Unfortunately, even if you had the physique of these world champions, and even if Sampras and Graf patiently explained the strategies of winning tennis, it wouldn’t be enough. It takes years of hard work, and most of us don’t have the discipline or persistence.

When it comes to reuse, we’re in a similar position. The good news is we have a world-class expert, Paul Bassett, who has written the best book about reuse I’ve seen in my career. The bad news is if you’re really serious about reuse, be prepared for a lot of work and a lot of practice. On the other hand, the really good news is that if you digest the book and apply its principles diligently, it really does work.

Ed Yourdon