I had the good fortune to be involved in the early days of the Software Patterns.  In brief, patterns are about capturing solutions that people have developed organically over time, which have proven to be the best ones for the context at hand. What's interesting about patterns to those who are used to more academic approaches to learning about software,  is that a good pattern isn't novel. If you've been working in a domain for a time you are likely  to recognize solutions you have used before. If you've struggled with the problem in the past, you are likely to appreciate that the "common solution" is now documented.

By writing patterns, and hanging around people who studied and and worked with patterns, I learned to appreciate that the value of context: it's not enough to have a toolbox of solutions; you need to understand which solution makes sense given the specifics of your problem. In that way, Patterns fit into a set that includes agile engineering practices and software configuration management: Things that help you to focus your energy on the solving the hard problems that apply to your specific situation.

A good pattern is something that other's have used successfully. When trying to understand whether something is a pattern or just a "cool idea" you often find your self trading stories with others who have worked in a similar domain. My work with "Patterns People" also helped me appreciate the value of story in sharing knowledge. The books that inspired the first writers of software patterns, The The Timeless Way of Building , and A Pattern Language: Towns, Buildings, Construction (Cess Center for Environmental), are about building and architecture, fields in which there is a long history and much tradition. Traditional approaches to building evolved organically over time, and the ones that worked were shared and persisted. To understand the difference between a solution that works and one that is adequate you need to know more that just what to do. You need to understand the story behind the solution, and the story behind your current situation.

The value of story in learning and transferring knowledge seem to make sense on the surface. But it also seems to contrast with the way that we sometimes apply business and engineering processes. We want highlights, key points, and simple rules. But we often don't have the patience for the story that describes why (and when) these rules apply. And applying rules without context can sometimes be uncomfortable.  I recently read a review copy of The Storytelling Animal: How Stories Make Us Human, and this book shed some light on why stories work well for learning, and why avoiding story can make us uncomfortable.

The Storytelling Animal a well written, compelling book that explores the science, history, and future of stories and storytelling. Among other things, the book covers why children and adults create and consume fiction, the science of dreams, the role of stories in influencing (and defining) history, and what technology means for the future of stories. Not just full of interesting facts, many chapters start out in the manner of a compelling story, drawing you into learning about the science and history of story telling, proving the point stories are a great way to learn.

In our quest for answers,  it is important to not ignore that there is a always a context to a problem. What worked in one situation might not be generally applicable, and a framework or tool that solves one (important) problem well, but not your problem is not de-facto a bad tool or a bad solution. Just not the right one for you. While it's good to be skeptical when presented with a solution (especially if someone claims it to be a pattern), it's also good to not be dismissive of attempts to capture solutions in context.  Solving technical problems well isn't just a matter of applying technology. You also need understanding and a knowledge of what others have done in similar situations. Your situation may well be unique. But it is also likely to be similar to ones others have encountered.