Before embarking on an experiment, it is useful to develop an explanation, or theory, of why the hypothesized phenomena might occur. If one just compares method A with method B without an idea of why they might differ, it becomes difficult to build a convincing experiment. If, on the other hand, one has a notion of what the underlying cause might be, one can design an experiment that hinges on this underlying cause. Otherwise, one is just fishing in the dark. Also, generalization suffers: one can only claim that the observed differences hold in situations that are close to the conditions under which the experiment was conducted. For learning more about the interdependence of theory and experiment, we highly recommend Chalmers’ book What Is This Thing Called Science? [Chalmers 1999].

Why might design patterns actually improve programmer productivity, software quality, and team communication? Chunking theory provides a possible explanation. This theory was first formulated in 1956, in George A. Miller’s famous paper “The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information” [Miller 1956]. His theory assumes that human memory consists of short-term and long-term memory. Short-term memory is fast and accurate, but its capacity is limited to about seven, plus or minus two, “chunks.” A chunk is a unit of information. Interestingly, the amount of information contained within a chunk is largely irrelevant. Long-term memory, on the other hand, has enormous capacity, but its recall is comparatively slow and occasionally inaccurate. In order to store information in long-term memory, humans must rehearse it, i.e., make repeated efforts to memorize it. Short-term memory requires no rehearsing; it seems to store information effortlessly, but forgets easily. When thinking, humans rely mostly on short-term memory, but when its capacity is exhausted, they also use long-term memory, which slows thinking down. For instance, when working with a large piece of software, programmers often go back and reread or recheck aspects they had already covered. A question such as, “How was this again?” is an indication of short-term memory overflow and the need to rehearse. Short-term memory acts somewhat like a cache in a microprocessor: if new information does not fit, older information is expelled. However, the expelled information is not automatically stored in long-term memory, unless it is rehearsed.

The limitation of short-term memory to about seven chunks is where design patterns might help: the patterns form units that group several design elements together. Without an understanding of the Observer pattern, for instance, a programmer needs to store four individual classes in short-term memory, plus the protocols for registration and update, using up several slots. If the programmer recognizes the Observer pattern, however, only a single chunk is needed, freeing up other slots for working on the rest of a design. Software designs typically consists of many classes, so this type of chunking could be useful. To help identify the chunks, a program’s documentation could simply point the reader to the patterns and the classes that belong to them. For instance, if the documentation points out the Observer pattern, the programmer would get a quick overview of the classes involved and might even skip studying the code for registration and update. In essence, design patterns help keep more of a design in short-term memory and thus enable faster, more comprehensive, and more accurate thought processes, which should manifest themselves in increased programmer productivity and software quality. Team communication would also improve. For example, rather than launching into a long-winded explanation of how some objects register and receive updates, a programmer would merely mention to a partner that certain classes constitute the Observer pattern, and that would be all that would need to be said. Specialized terminology does have its advantages!

Though plausible, nobody knew whether design patterns would really exhibit the hypothesized phenomena, but chunking theory helped with developing suitable experiments. The experiments would need to test programmer performance when working with sets of classes or other software elements occurring in design patterns. The tasks would have to be large enough to tax short-term memory, but not huge. Differences could come from two sources: a more accurate grasp of the software by using patterns, or by having more short-term capacity left over to do other things. As the actual load on short-term memory is difficult to establish, the experiments here deal with the former approach.