Skip to main content

Patterns and The Storytelling Animal

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.


Comments

Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…