I was out walking with my two-year-old son last week when we crossed the street next to a person on a motorcycle. From the running commentary in the stroller emerges “the man on the motorcycle is going to school.”

Umm…..huh? “Hey bubba, how do you know the man is going to school?”

“Because he is wearing his backpack.”

Patterns, a topic that was covered on the blog just a few weeks ago, was having its power illustrated to me first hand. My son, who loves wearing his brand new backpack to school, was vocalizing one of the key patterns from his world. Patterns are so simple that a two-year-old can pick up on them with zero prompting, yet so complex that hordes of engineers are still spending millions of man-hours trying to teach them to computers.

Although I enjoyed the post that discussed Yahoo’s design patterns, it made me realize that my understanding of patterns is based purely on hearsay as I have never read any source material on the subject. I went searching for a decent primer on the topic and came across this post by Brad Appleton.

Brad starts his patterns essay with what I think is an excellent definition of the concept:

A pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces.

Brad goes on to provide some characteristics of design patterns, this time quoting from James Coplien’s work on the subject. According to Cope, a good pattern does the following:

• It solves a problem
• It is a proven concept
• The solution isn’t obvious
• It describes a relationship
• The pattern has a significant human component

From there, Brad dives deep into the source material and key players behind the pattern revolution including the GoF, GoV, and numerous other engineers who have advanced the cause. It is clear that what started out as architect Christopher Alexander’s grand attempt to enable every citizen to design and construct their own home has morphed into a driving concept in fields ranging from computer science to organizational behavior. I will not attempt to go into the source material in any greater depth here because I know I cannot do it justice, but I would urge anyone that is interested in the world of design patterns to use Brad’s paper as a jumping off point.

Why are patterns so powerful? It’s simple – because this is the way we are wired as human beings. Pattern recognition is the first higher order skill we use as infants when we learn to recognize our mother’s face, and it is arguably the core mental ability that plays the biggest role in molding our adult selves from the lump of clay that represents our childhood experience.

What this means for me from a requirements perspective is that although their power ensures that patterns are a topic that I will keep on my list of ongoing research topics, it is only with the realization that the strength of patterns can often hurt us in our software requirements efforts. Where is the danger? Unfortunately, the human mind is adept at identifying patterns even in cases where there are none. How many times has a requirements engineer heard the phrase “this is exactly like XYZ” only to learn through careful elicitation that it is exactly like XYZ 10% of the time but nothing like XYZ the other 90%. As we strive to create a library of requirements patterns we must pay great heed to Brad’s observation that “documenting good patterns can be an extremely difficult task” and not fall into the soothing hype of patterns being “sugar and spice and everything nice.”