While I’m not the foremost expert on patterns, I have a little familiarity with them. Chiefly, I’m aware they were adopted and adapted from a work by Christopher Alexander, an architect, in which he attempted to create a language with which anyone—not merely architects and builders—could efficiently and effectively communicate about built aspects of our world, and what works well, and why. And I’ve read many books which more or less acknowledge Alexander’s influence on their own ideas.

And I’m left with this thought. The scale is way, way the hell off.

Alexander promoted patterns for a metropolis, and patterns for a small part of a building, and everything in between.

But most software design patterns are focused around the code or processes used to create software.

To me, it’s as though software design patterns, if they were directly transferred to their counterparts in the building and architecture world, were describing minutiae. The seminal work, the Gang-of-Four’s book Design Patterns: Elements of Reusable Object-Oriented Software, focuses on object-oriented coding patterns. In buildings, that would be like patterns for attaching boards to each other, for leveling a floor, for digging a square hole in which to put a foundation, for connecting ducts, for making sure screws and bolts turn “righty-tighty, lefty-loosey.”

If I’m about to buy a house, I really don’t care that much about those things. That’s stuff that the carpenters, the masons, the plumbers, and the heating/cooling technicians need to know. Should they know those things? Sure! I’m not saying patterns at those levels aren’t important. But they’re worthless for me, as the user of the house, to know about.

If I’m about to buy a house, I really need to be able to evaluate a house or express my ideas for a house in a much larger, much broader way that really doesn’t care about how it gets done or what construction patterns were used. I need a language where I can share my thoughts with the architect or with the general contractor.

We have no such language right now. When I try to describe potential software solutions to people, it’s almost like I’m trying to describe the materials or processes by which the building gets built, but not really the functional aspects of how it will work for the user. Or, I’m describing the functional aspects of the software, but it’s not clear from that description whether I’m describing something simple, commoditized, and cheap like a kitchen sink (“the function is to wash dirt off hands, dishes, and food”), or something large, intricate, built-to-order, and expensive like an automatic cat and dog groomer (“the function is to wash dirt off dogs and cats”).

We need that language in order to more effectively discuss solutions with our customers.