Computers, patterns, humbleness

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:

The most obvious case for patterns:

One such strategy is to share knowledge and base our solutions on what has been known to work well in the past. Since few designs are really novel we often find that previous solutions, at least on a conceptual level, apply to our new problem too…

Patterns incorporate both of these strategies. As software developer and author of a technical book on patterns I obviously find value in the pattern format. And as a psychologist I see the links to our cognitive capabilities and the social value of patterns.

And patterns have a cost and can be abused:

Atwood has a point; patterns are indeed used in situations where they don’t apply. Sometimes that’s a good sign. At least in a supportive environment. A willingness to try something new is a sign of intrinsic motivation. It’s an attempt to improve. We need to make those errors and learn from them. The challenge is to provide an environment where the consequences are controlled. A mix of mentoring and peer reviews has proven to be a successful approach. Direct feedback is an important learning tool.

…Patterns aren’t necessarily good. Used in the wrong context where the forces are unbalanced they make the resulting context worse. Patterns, like any other design choice, imply a trade-off. We buy flexibility in one area traded for some other consequences. Unless the flexibility is required we travel into the obscurity of speculative generality. A simpler solution would probably serve both the business and the brain of the maintenance programmer better. Or, as I put it in my book: “maintaining an AbstractFactorySingletonDecoratorBuilderPrototypeFlyweight isn’t why I went into programming” [4]. Believe me, I’ve been there. There’s just no supplement to good taste.

Perhaps patterns can be used as short-term stand-ins for the eventual truth you hope to discover? Perhaps you can start off with a Factory pattern because it is common, and only much later realize that you will use macros to generate custom loop comprehensions?

When used as targets of refactoring, patterns do shine. One of the reasons is that the resulting context is well documented. It’s possible to reason about the changes up-front and contrast them to the existing implementation. A refactoring is an investment that we want to pay-off. Any good pattern description acknowledges the weak sides of the pattern, its trade-offs and hints at scenarios where the solution doesn’t apply.

And they have social value:

Patterns have social value too. The format arose to enable collaborative construction using a shared vocabulary. In Patterns in C I write on the groundbreaking work of architect Christopher Alexander:

“The patterns found in Alexander’s books are simple and elegant formulations on how to solve recurring problems in different contexts. [...] His work is a praise of collaborative construction guided by a shared language – a pattern language. To Alexander, such a language is a generative, non-mechanical construct. It’s a language with the power to evolve and grow. As such, patterns are more of a communication tool than technical solutions.” [4]

Patterns in the original sense are context-dependent and do not by some work of magic provide universally “good” designs. You can’t take the human out of the design loop. This is why I get disappointed every time I see someone offering a “patterns code library” or expensive case tools that come stacked with “UML pattern templates”. Reducing patterns to mechanisms doesn’t tell the full story. The most interesting part of a pattern is rarely the implementation.

I understand the marketing perspective but those ideas completely miss the very essence and purpose of patterns. Sure, in software we are free from the physics that constrained Christopher Alexander. We may take a natural departure from Alexander’s idea and provide general parameterizable implementations of specific patterns. If we do our job right that abstraction may well be usable, yes, sometimes even re-usable. But the ROI is diminishing fast.

Jeff Atwood falls into this trap as he labels the whole idea “a complex recipe of design patterns” [2]. Design patterns are not a “recipe” either and were never intended as such. But Jeff’s view is an understandable outcome of skimming through Design Patterns by the Gang of Four [6]. One of the main problems I have with the Gang of Four book is its prominent use of class diagrams. Open any pattern in the book. First thing we see is a class diagram.