Patterns for two-year-olds
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:
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.”
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
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.”
posted by Anonymous at 3/13/2006 09:51:00 PM
1 Comments:
Christopher Alexander went on in later years to abandon his patterns and seek emergence as a solution to the sameness of patterns.
Patterns in the software world are about architecture and design, not requirements. If there are requiremnts patterns, and there probably are books on that, then an elicitor's biases would just be enhanced in opposition to the need for accurate requirements. The elicitation process is already overburdened by elicitor bias.
Unlike what they teach us in school, the elicitor decides what to build before the first user is elicited, and once you start eliciting users the early ones carry the most weight. After these strongly biased processes occur, then comes the negotiation over the requirements. And, once published, the political macinations begin, which makes accurate requirements near impossible. That software applications succeed at all happens at the expense of user efficencies even with perfect GUIs. Operational managers end up hiring more people to take care of all the holes in the application they discover through use. The Operational manager can't afford to pay for modifications, so the developers never know that they failed. Worse, some of the operational costs are invisible just by the nature of the accounting system and what it can count.
Post a Comment
<< Home