Design patterns are reusable solutions for design problems. They became popular in 1995 with a famous book by Erich Gamma et al. [Gamma et al. 1995]. Before design patterns were introduced, programmers had only a few general design principles to guide them when structuring software. These principles included the information hiding principle, which says to equip software modules with change-invariant interfaces. This principle assures that the insides of a module can be changed while keeping the interface the same, and therefore none of the software using the module needs to be updated. The principle was formulated by Parnas [Parnas 1972] in response to the observation that software changes frequently.

Design patterns go further than general principles: they suggest solutions for concrete design problems. In that sense, design patterns are to design what algorithms are to programming. Both algorithms and design patterns provide solutions for concrete problems. For instance, Quicksort provides a solution for sorting, whereas the Observer pattern is a solution for sending updates to interested software components. Textbook algorithms usually are not executable, because they are formulated in pseudo-language. The programmer must map them into the target programming language and make other adjustments. Similarly, design patterns are not finished designs. Instead, they describe a general software structure or interaction between software components that still must be adapted to circumstances.

Proponents claim the following advantages for design patterns:

In the early years of design patterns, nobody knew whether these claims were true. At the time, experienced programmers had already lived through many programming fads and were unwilling to spend time and energy on another one. The zoo of design techniques was already crowded; it included structured design, functional design, data abstraction, modular design, object-oriented design, multi-paradigm design, architectural styles, refactoring, and others. Why would anyone waste time on something new and unproven called design patterns? But what if they were actually a good idea? How could we resolve this question? Should we rely on the authors of pattern books, personal experience, or the wisdom of consultants? All these were subjective or self-interested in some way. To objectively test whether the claims were true, there was only one way: objectively observing programmers in their work, or more precisely, conducting a scientific experiment. The experiment would measure the difference between using design patterns and not using them. If design patterns were such strong productivity and quality enhancers as claimed, then some difference should be measurable. Given the broad claims about patterns, a single experiment was not going to test all of them. So my students and I decided in 1996 to embark on a series of experiments. In the process, we not only learned a lot about design patterns, but also a lot about experimental methods in software research. But before reviewing them, a brief look at patterns will help grasp the ideas behind them.