In preparation for my talk at Mile High Agile 2013 on Friday, I asked this question on a few social networks:

“I’ve been interested in the answers I’ve gotten on other social networks, so I’ll ask this here: If you were giving a talk on design patterns to non-technical people, what one or two nuggets of wisdom would you impart?”

I wanted to accumulate some of the answers and discuss them a bit.

The first response was from Pedro:

I would say that is a framework to solving recurring problems for software engineers that allows them to define implementation solutions. Similar to self-assemble kits for custom furniture. Kits that are not a complete product, but provides enough guidance to having a custom finished and unique piece of furniture.

I like the analogy to furniture assembly kits. There are a good example of creational design patterns. The kit itself was created by an Abstract Factory, which is a pattern for creating a set of related things. The consumer, when they get the box home, acts like a Factory and assembles the piece of furniture.

Neal likened it to a toolbelt:

[A] non-technical way of looking at design patterns is a carpenter’s tool belt. It’s filled with objects that allow him to quickly accomplish common and repetitive tasks. If he needs to pound nails, he grabs the hammer, he doesn’t build one from scratch every time he needs it. From the 50,000 foot level that’s really what they’re about.

I agree with Neal in that design patterns are tools of the trade for programmers. The analogy of a tool belt breaks down in the physical world, which is why I think Mark E took exception to the hammer analogy:

Isn’t it more along the lines of using a pattern to design something that you are building? For instance, if you are framing a wall you don’t just start hammering 2x4s together. You design the wall. You space the studs, you run the wiring… You have a plan. It’s been done before millions of times. Find out the pattern for building the wall and repeat the pattern. Don’t just ignore the fact that someone has solved this problem before.

In another thread, James H cautions about finding patterns everywhere:

Doing something once does not make it a pattern. Patterns emerge over time from similar solutions being effective at solving a problem. Related: Solving a problem by using a pattern is less likely to be effective than solving your problem in a way that makes sense and then moving toward one or more patterns once you recognize the applicability.

My favorite response was from Brad M, who isn’t a programmer by trade:

“You already do this reflexively in your daily life, but by formalizing it you will be able to use it deliberately and more extensively.”