9.1 A Little Starting Context

The initial context for software patterns was object-oriented design. Software developers, particularly object-oriented ones, started getting interested in patterns ten years after Alexander's patterns books in the late '80s and only in a very small way at first. Software patterns emerged out of a number of needs that were becoming very evident then. Thomas Kuhn would have called the emergence of these needs crises: situations that challenge the existing way of doing and knowing, and so they provoke new paradigms. I'll treat them as forces, in the Alexandrian sense: conditions that need to be resolved to establish a new balance in an unbalanced situation, creating a new "wholeness."

9.1.1 Force 1: Structuring Abstraction, Abstracting Structure

The coming of patterns was driven by recognition of the need for a higher level of abstraction than objects and classes in object-oriented design. Peter Coad, a pioneer in the pattern movement, put it this way in an early article he wrote for the ACM that reflects Alexander's influence:

Object-oriented methods tend to focus on the lowest-level building block: the class and its objects Classes and objects correspond to Alexander's constantly repeating, lowest-level elements. Patterns of lowest-level elements and relationships between them form a building block for more effective OOA and OOD (Coad 1992, 152)

This need reflected a force in software development that had been gaining steam since the late '70s: the trend toward structuring systems and, whenever consultants could get away with it, structuring enterprises as architectures. The increasing complexity and interdependence of business systems made the old one-at-a-time view of applications unworkable, even within the narrow confines of COBOL, JCL, and mainframe databases.

By the late '80s, objects which started life as ways to program simulations and children's games became both the silver bullet for structuring the complexities of interconnected systems and the first real justification for treating the idea of software architecture seriously.

However, while seemingly solving key parts of the managing-complexity problem that the first generation of commercial software tools created and couldn't solve, objects created another level of complexity that needed to be managed. Structured programs could be composed of procedures, modules, and files chunks that made physical and logical sense but objects were well, objects. Although structured developers had a substantial arsenal of tools for organizing their work and their designs, object-oriented developers lacked any such facilities. So, developers asked, "How can we organize these things called objects?"

The answer: software architecture. And maybe patterns:

Mature designers are able to see the broad patterns in the software architectures they work with Procedures, objects, and [other] abstractions provide the building blocks: patterns provide the overall architecture. (Coplien 1994a, 1)

Patterns also provided a convenient language that was distinct from the old language of procedures and modules (not just a step up in abstraction from objects) for this new kind of architecture:

Patterns have given us a vocabulary to talk about structures larger than modules, procedures, or objects, structures that outstrip the vocabularies of the sound object design methods that have served us for the past decade. Many of these structures aren't new; a few people have known them for decades. Patterns bring these techniques, and a vocabulary to talk about them, to the everyday programmer. (Coplien 1997, 36)

9.1.2 Force 2: Guiding Creativity, Creative Guidance

By the late '80s, object-oriented design was maturing, and the traditional methodologies and first-generation object-oriented methodologies were not up to the task of packaging and communicating what was being learned.

A mundane need for a decent set of repeatable guidelines for object-oriented design and programming was emerging guidelines that reflected the interactive quality of the technology. These were needs not being addressed by the methodologies of the day:

The search for an appropriate methodology for object-oriented programming has seen the usual rehash of tired old ideas, but the fact is that OOP is so different that no mere force-fit of [traditional] methods will provide access to the potential inherent in OOP these methods [do not] address the user interface design issues [and] while E-R [for example] seems to be "object-oriented" it is not suited to the dynamic nature of objects and encourages the use of a global perspective while designing, a sure loser in object-oriented programming We propose a radical shift in the burden of design and implementation, using concepts adapted from the work of Christopher Alexander (Beck and Cunningham 1987)

Patterns were seen as offering an alternative way of documenting techniques an alternative more in synch perhaps with the world of interactive, object-based software development. By being self-contained and yet connected, they resemble objects. Patterns reflect targets implicit in object orientation, such as independence of language and platform, and adaptability to circumstances:

The pattern form is well suited to documenting [object -oriented] design techniques. Unlike a design document, a pattern reflects something that has been used in a number of situations and thus has some generality Patterns also express solutions in ways that allow for some variation depending on the details of a circumstance. Finally, patterns can express architectural considerations independent of language and design methodology (Berczuk 1994)

And, by being generative (a source of creative solutions) rather than prescriptive, patterns require an interactive involvement by the pattern user:

A generative software design pattern can be used in the same way we use a dress pattern or a boat pattern: to guide a designer to build a new dress or boat. We can weave patterns together into generative pattern languages, families of related patterns which together provide a solution set for system-building problems in a single domain. (Coplien 1997, 36)

Generative, a favorite term in the literature about software patterns, is inherited from Alexander. It suggests an indirect creativity, a way of providing the direction for a creative solution without detailing how to achieve it.

Along with a dissatisfaction with the prevailing methodologies, patterns also reflect a healthy disrespect for Computer Assisted Software Engineering (CASE), the previous silver bullet that proved so disappointing and expensive. CASE ended up automating obsolete techniques and practices. In the end, automating the design process for software turned out to be as fruitless as the search for a way to "mathematicize" the design process in architecture that led Alexander to patterns.

9.1.3 Force 3: The Search for Quality and Reuse

Additional forces that supported the idea of patterns came from an emerging emphasis on software quality. In object-oriented programming, software quality combined with a focus on the possibilities of increased development productivity through reuse. Objects with patterns as an organizing principle offered the tantalizing possibility of reuse at a higher level than raw code: design artifacts, architectural elements, and, ultimately, experience:

Patterns are forms for describing architectural constructs in a manner that emphasizes these constructs' potential for reuse. They provide a way to document and share design expertise in an application-independent fashion (Berczuk 1994)

Patterns were also seen as a means for including the human element and a degree of evolutionary process into the arena of software quality and reuse:

We believe the goals of software quality and productivity will be best served by the methodical cataloging of successful designs we remain inspired by the impressive design catalog assembled by Alexander [He] claims most good architectural ideas evolved out of uncountable generations of people building structures for their own need. These ideas, passed on from generation to generation, were subject to a form of natural selection We find much encouragement in Alexander's tactic for reintroducing selection into a field of design recently taken over by [the] disinterested. (Rochat 1988)

9.1.4 Broader Cultural and Professional Forces

Any discussion of the context for understanding patterns would not be complete without some discussion of the intellectual and cultural currents that were flowing in the period when software patterns emerged. The feelings expressed by Rochat and Cunningham reflect a more general force that surfaced then: a desire for what Ivan Illich, one of the key social critics of the Baby Boom decades, called "virtuous practice" in the face of "deskilling," specialization, and constant change.

Ivan Illich co-authored a declaration that suggests some of the broader social context behind the patterns movement:

Virtue is embodied practice which can only exist where custom has shaped and limited a field for its application. By virtue, we mean that shape, order and direction of action informed by tradition, bounded by place and qualified by choices made within the habitual reach of the actor. (Cayley 1992, 48)

These feelings also reflect the desire for the "demystification" of professional knowledge, which Donald Schon discusses as being embraced by many professionals during the '80s. He offered the "reflective practitioner" as a model for professionals looking to open up what they do and how they do it to the outside world and within their community a strategy very much in keeping with the emergence of the software patterns community.

Patterns provided a convenient way for documenting the "custom" of software development in a field overrun by urgent novelty, the loss of personal control, and ever-shifting boundaries. The patterns community provided a good, old-fashioned town hall environment for sharing and demystifying technical knowledge.