1.1 Patterns and Paradigms

In his now-classic book, The Structure of Scientific Revolutions, Thomas Kuhn appropriated the word paradigm, twisting the meaning to suit a new need. Kuhn used it to mean significant achievements that share two characteristics:

They are "sufficiently unprecedented to attract an enduring group of adherents away from competing modes of activity."
They are "sufficiently open ended to leave all sorts of problems for the redefined group of practitioners to resolve" (1970, 10).

Kuhn's appropriation was so successful that paradigm has now been even further appropriated to the point of becoming jargon.

His meaning, his associated notions of revolution, and the change in world-view that results are the most useful starting points for understanding patterns and the Unified Modeling Language (UML). Kuhn's analysis of the way that a paradigm shift reshapes the workings of the normal world is the best explanation for events that have taken place in the last half-decade in software development.

Kuhn explained how a new paradigm emerges from a revolution in ideas. This makes it possible afterwards for scientists to engage in what he called normal science: a scientific practice in which the definition of what constitutes a problem and what is acceptable in arriving at a solution are both provided by the significant achievements that constitute the paradigm shift. Seen this way, new paradigms are not about revolution, but rather about getting the job done. After a new paradigm is established, sensible and conventional people rush in. The new paradigm provides the tools and examples that everyone else can use in figuring out what the revolution means and in applying the revolution.

The normal world Kuhn describes was, until the advent of the information age, limited to the only real knowledge workers that existed before the computer: scientists and academics. Now, what Peter Drucker calls knowledge workers and Robert Reich calls symbolic analysts are the people who are problem-solvers in the new knowledge-based economy (Nonaka and Takeuchi 1995, 7).

Ironically, the conventional meaning of paradigm that Kuhn reworked, which has now almost disappeared as a result, is that of an accepted model or pattern. In later revisions of his book, Kuhn accepted that the multiple meanings he attached to paradigm were confusing. He responded by suggesting that exemplar might be a good term to add to paradigm. By suggesting this term instead, he meant the patterns of experience that science students were exposed to in their studies, expressed as problems that had to be solved in the course of mastering science. This is very much like one of the intentions of software patterns: to provide examples of problems, as solved by the masters, which can be learned from by the inexperienced.

The new paradigm in software development, which is reshaping the world of both software developers and users, is substantially based on patterns and models. The patterns movement and the accepted approach for software documentation that is embodied in the UML are both critical elements in a revolution that is transforming software development at the end of this millennium a revolution that is finally starting to live up to the hype of what computers can do for the rest of us.

1.1.1 The Idea of a Pattern

Defining a pattern is one of those deliciously difficult exercises that challenges the easy boundaries we all usually want to place around ideas. According to the Oxford English Dictionary, a pattern is "a regular or logical form," "a model, design or instructions for making something," or "an excellent example." In software development, all of these meanings apply.

As "a regular or logical form," patterns are now an accepted way of packaging software design experience (specifically, object-oriented software design experience). Even with the variety of formats that have been used by pattern writers, there's an underlying similarity that binds all software patterns together.

The simplest way of explaining the usefulness of patterns is embodied in the second definition, especially the idea of instructions for making something. Fundamentally, patterns are about crafting things think of sewing patterns and recipes, each of which are open to adaptation by experienced users. Patterns are not about engineering, which requires blueprints, building plans, and other conventional documents that are specific and (ultimately) legally binding. Instead, they enlighten the normal processes of designing and building the ways ordinary craftspeople make things.

However, as I suggested earlier, they complement models and other engineering tools in two very practical ways. First, they explain the logic of the problem being solved, and then they provide the guidelines for solving the problem. Used properly, patterns help ordinary craftspeople to do extraordinary things.

For this book, I'm concerned with crafting software and the organization, architecture, and processes needed to craft it the infrastructure that makes such building possible. But, unlike a methodology, these instructions are not hard and fast rules in a logical sequence of well-defined activities. Rather, they're closer to cooking recipes open to experimentation to be combined in creative ways to make a meal.

An understanding of the power of patterns comes from the third definition patterns as "an excellent example," providing a non-prescriptive source for initiating and guiding the creative aspects of software development. They provide starting points for novice developers, reminders for experienced developers, and a way of sharing lessons learned.

There are other informal definitions that also help round out an understanding of why patterns are so important in software development:

From a broad perspective, a pattern can be seen as a form for documenting best practices. In a profession that lacks centuries of experience and scientific underpinnings of engineering or architecture, best practices have become a touchstone for ensuring that risks are understood and that commonly accepted techniques and technologies are used. Patterns provide a standard format and repository for them replacing what has been, until now, anecdotal reporting and documentation of the best ways to do things.
From a narrower perspective, a pattern can be seen as a rule of thumb: a heuristic quick way of providing a starting point for solving a problem. The craft of software development has generated many rules of thumb in its brief history. Patterns can provide a home for them that is formalized without being fussy.
Finally, and even more narrowly, a pattern can be viewed and used as a template. This definition captures a critical aspect of patterns: they can be applied over and over again, in different situations. They are not specific solutions, but rather the basis for a solution. And, in software development, they derive from the fact that software solutions themselves tend to be repetitive. There is only a small set of solutions for any design problem in information systems, whether the problem is in software architecture or in development organization.

These definitions are drawn directly from the systems community. They suggest that patterns, in many ways, provide a more organized and consistent way of communicating by replacing previously existing methods for sharing experience and knowledge. In short, they suggest that patterns are simply a more effective way of capturing and expressing the developer's tacit knowledge than, for example, traditional methodologies, by making such knowledge explicit and available for all in a convenient and general form.

Of course, there are more comprehensive and formal definitions of a pattern that come out of the work done in the patterns community. I'll discuss these in detail in Chapter 9. The more formal definitions and associated philosophies have a place, but they are not critical to evaluating and applying patterns for the average user.

In this book, I don't slavishly support any one definition of a pattern. I consider all of the informal definitions to be useful, because they can provide a way to start thinking about and using patterns. However, there needs to be a more rigorous working definition to help make this book useful.