Lessons learned

Despite our diverse backgrounds and experiences, several common lessons can be drawn from our own experiences with patterns as well as from our colleagues in the patterns community. Table 1 shows the sources of the summary observations listed below. Although in some cases it is difficult to give a binary answer, checkmarks indicate that this company has made this experience. Unfortunately, we do not have any measurable data on the impact of patterns available yet, at least not in a form we could currently publish. But the consistency among our experiences with patterns, leads us to believe in the value of lessons listed here.

Patterns serve as a good team communications medium.

Typically, when several pattern-aware software developers are discussing various potential solutions to a problem, they use the pattern names as a precise and concise way to communicate complex concepts effectively.

Patterns are extracted from working designs.

Each design pattern discussed above was extracted from existing, working designs (and in the case of the organizational patterns of AT&T, from existing organization) and not created without experience. The design patterns capture the essence of working designs in a form that makes them usable in future work, including specifics about the context that makes the patterns applicable or not.

Patterns capture the essential parts of a design in a compact form.

This compact representation helps developers and maintainers understand and therefore not contort the architecture of a system. Making this often only implicitly understood knowledge explicit allows for more effective software development.

Patterns can be used to record and encourage the reuse of ``best practices''.

This is especially important for helping less-experienced developers produce good designs faster. A collection of design patterns in handbook-form is useful for teaching software engineering. However, note that, in partial contrast to handbooks from other engineering disciplines, a design pattern is not a rule to be followed blindly, but rather it should serve as a guide to the designer and/or provide alternatives when being applied to a particular situation.

Patterns are not necessarily object-oriented.

Although the design patterns as we describe them come from the object-oriented community, there is nothing inherent in design patterns that makes them object-oriented. Not coincidentally, there is nothing inherent in object-oriented programs that make them candidate sources for design patterns. Our experiences have shown that design patterns can be found in a variety of software systems, independent of the methods used in developing those systems.

The use of pattern mentors in an organization can speed the acceptance of patterns.

Pattern mentors can help provide a balance between encouraging good design practices based on patterns and discouraging overly high expectations of designs based on patterns. Initially, pattern mentors can help developers recognize the patterns that they already use in their application domain and show how they could be reused in subsequent projects. Pattern mentors should also watch that the wrong patterns are not applied to a problem (i.e. people tend to reuse things that they know and the same temptation will apply to patterns, regardless of whether the pattern actually fits the problem).

Good patterns are difficult and time-consuming to write.

Writing good patterns is a skill that does not come easy. Furthermore, the writing of a pattern typically involves an iterative process in which the pattern is presented to others and/or applied in projects, relevant comments are incorporated, and the process repeated until the result is adequate. However, we have found that, as one gains experience at writing patterns, the effort for recognizing and writing them is reduced.

Pattern practice is of utmost importance.