Patterns and Heuristics

This column celebrates the 20th year of software patterns. IEEE Software advisory board members teamed up with members of the Hillside Group, a nonprofit organization that promotes the use of patterns and pattern languages, to reflect on the state of the practice and impact of patterns.

Capturing the wholeness of design solutions in order to effectively communicate them to others can be challenging. We posit that patterns are observable phenomena of design solutions. To represent these phenomena, a pattern author needs to generalize and omit information. Experienced designers are able to unfold the essence of the pattern and generate design solutions based on the information that they do find in a pattern description. Not surprisingly, their personal design heuristics play a central role in this. As they create a design solution, they also liberally apply their pre-existing design know-how and heuristics. But novice designers may have more difficulty. As this folding and unfolding of information and knowledge seems to be quite an abstract concept, we have chosen to make our point by discussing elephants. Like patterns, elephants are an observable phenomenon, a pattern in nature. Many different descriptions, representations, and accounts of elephants exist. Many people claim to know what elephants are. Yet they actually have little or limited knowledge of them. This analogy helps to understand how at the same time we both know and do not know what a thing is.

As patterns authors, we spend a lot of time writing. Usually our work is driven by what we want to share of experiences, working solutions, and ideas we are excited about. But how often do we think about the readers other than initially stating our intended audience? Who is going to consume our writing, and are we really putting in the effort to reach these readers in the best way possible?

This paper started because we are two authors who plan to make a book from a set of related patterns papers, and in doing so we really want to reach our target audience and provide a practical and useful piece of work. Our approach had two distinct investigation activities. One was to do an informal analysis of books about software processes and methods to gain a better understanding of characteristics and book design practices for this kind of book. The second was to use a combination of interviews and surveys to gather feedback on what readers are looking for when accessing information about software engineering. To better understand our potential readers and how to design our writing for their consumption, we created personas where we incorporated feedback from the reader survey into their personalities and preferences. Finally, we combined our information sources to create guidance for our future work of turning a set of patterns papers into a cohesive whole.

Elephants are an observable phenomenon, a pattern in nature. Software patterns are observable phenomena of design solutions. Many different descriptions, representations, and accounts of elephants exist. And many people claim to know what an elephant is. Yet they actually have little or limited knowledge of them. This analogy helps to understand how at the same time we both know and do not know what a thing is. This talk will explore the dilemma faced by patterns authors: What to include in a pattern and what to leave out? We also show how experienced designers unfold and generate new solutions based on pre-existing design knowhow and the central role personal design heuristics play in the design process. As this folding and unfolding of information and knowledge seems to be quite an abstract concept, we will choose to make our case by discussing elephants.

This essay reflects on my experiences of the past 15 years writing software design patterns and posits that if the patterns community wants to broadly increase pattern literacy, relevancy, and long-term impact, some things need to change. Those changes need to start with pattern writers—like me. Instead of indiscriminately writing ever more patterns, we should focus more on connecting, relating, and refreshing the abundance of existing impactful patterns. Changes also need to be made in how we the community of long-time pattern authors and advocates present and promote patterns to the rest of the world.

This is an about paper—one that we write to gain a better understanding, for ourselves and our readers alike, of the usefulness of a pattern language and what it takes for experience captured in pattern form to be of use to others. In it we look at what it means for individual patterns and collections to be generative and explore some differences between those that are highly generative and those that are not. We ask whether software design and software process patterns can be generative and, if so, what is their potential impact. Finally, we draw some conclusions on how these thoughts on pattern generativity could influence future writing of and support for generative patterns.