October 15, 2003

Pattern Recognition

Filed under: digital — mhoye @ 3:56 pm

“As with most things fanboy, those who are vaguely familiar with the term seek to ingratiate themselves with others by almost getting it.” – Jim Hill

Pattern programming is hot-hot-hot in my faculty right now, this month’s Way of the Future; it will make us better programmers, our lives will be easier and more fruitful, our code will both taste great and be less filling. And, tragically, it’s a load of bullshit.

Harsh words, I know, and unless people are asking who’s fault that mess is I am rarely regarded as an authority. But true, nevertheless.

I think this is partly because damn near everything that involves computers is, to some degree, bullshit. This is a well-known but not widely understood phenomenon; people often declare that the field of computing is a young field, without the decades or centuries other fields have behind them, but not a lot of people realize that computing as an industry is in its teens, and Justin Timberlake is, like, the greatest thing ever, omigawd. And like all things aged teen once a fad gets enough traction in the popular consciousness to really get rolling, that momentum is reason enough for it to keep going – if people just keep buying the product why not? Everyone wants to fit in, all the cool kids are doing it, so forth.

But the other reason it smells like bullshit is because if you actually go back to the original documentation, you get a clear view of an entire academic subfield that is diligently and industriously missing the whole point.

Pattern programming is a child of UML, a graphical notation for object-oriented code that’s supposed to turn large-project management into something that project managers can understand. It’s third-generation hype, essentially. The revolutionary idea of pattern programming is simply that it turns out that in programming, unlike every other human endeavor in the history of the universe, the same problems seem to crop up over and over again. Further, those problems tend to have common and well-understood solutions associated with them. The details might be different, but the overall approach is pretty much the same. This overall approach is what is described as a “pattern”.

All of the “Programming Pattern” references you’ll find eventually lead back to a guy named
Chris Alexander, a professor of architecture whose book “A Pattern Language” is invariably described as the starting point for the whole thing. This is done, I think, for the very good reason that Chris Alexander is a genius and anyone who designs anything for anybody should read it instantly. He has outlined an astonishingly powerful idea in that book, and the overall gist if it is this: if you, as an architect, are building an edifice of some kind for a group of other people, or several other groups of people, then you are confronted with a problem in two parts:

  1. The people whose workspaces you are designing know far more about what they need in that space than you do, and
  2. You are responsible for creating a building with a unified overall aesthetic, which those people can use.

So odds are good that, say, the chemistry department is going to know more about how to set up a lab properly than the architect ever can; extend this idea to the dozens of other groups that might be in your building, and the basic idea is that if you just give all these people a space and tell it to furnish it themselves, you’ll get a bunch of disjoint, cobbled-together rooms that don’t look anything like the next room over, which may or may not work the way the occupants were hoping. Likewise, if you design it all yourself, you’re inevitably going to give your clients something they neither want nor can use.

Alexander’s solution to this is the brilliant bit, the idea of a “pattern language” that divorces the aesthetic details of form from function and shape, and puts as much power as possible in the hands of the designer’s clients. As one example, he suggests “table”, “sink”, “closet” and dozens of dozens of others; the architect then gives this stripped-down descriptive language to the future residents, along with the outline of the space they are going to occupy. Those residents can then say “Ok, we’re going to need a table here, some desks over there, some sinks here, some closet space there”, and so on. And when they’re done, the architect says thanks, takes the designs back and builds a chemistry lab to the residents specifications, guaranteeing that the desks in the chem lab have the same color scheme and trim as the study lounge or the Dean’s office, or whatever.

The architect has thus achieved unity of design, and the residents have a place that works exactly they way they asked.

I say again, this is an extraordinarily powerful idea, both technically and socially.

Somehow, though, in my field this idea has been devolved into a glorified way of writing manuals. Common “programming pattern” references that cite Alexander as their root source are just catalogs of relatively trivial techniques that are used to solve minor architectural problems. If you spend a lot of time looking at UML diagrams and you eventually start seeing the same things over and over again, those are “programming patterns”; They’re the Magic Eye hidden in control-flow charts; if you cross your eyes just right, you can almost see the dinosaur. In any other field, everything that’s been written so far about programming patterns would be written up as a quarter-inch-thick quick reference that you could pick up in the Chapters “home projects” section. Curious novices would be able to pick up the “For Dummies” version, and nothing more would be said about it. But not here in teenaged-industry-land where, omigawd, patterns are the awesomest thing ever. It’s like finding out that Danielle Steele has won the Nobel Prize for Literature for the fifth year running; it’s disheartening, and we just have to be capable of better than that.

It’s nice that these approaches are being codified, I guess, but it’s hard to call it earth-shaking when the profoundly obvious is written down. Still, it’s laudable that things that work get written down for posterity. The claim that it’s got anything at all to do with Alexander’s idea is patently false, but I’m sure it’s no surprise to anybody that computer people don’t really want to read the documentation. Reading for comprehension is hard.


  1. Having lived on both sides of this, I can say with some authority that you have completely and utterly failed to make whatever case it is that you were trying to make here.

    I was on a project where the tech lead used nothing but patterns throughout. It was the most ridiculous, overly-general, complex (and yet very powerful, I must admit) piece of shit I’ve ever had to use. The client eventually threw the whole damn thing out in favor of an HTML-only site. I shit you not.

    On the other hand, there are certain patterns — Factory, Singleton, and Composite (if you don’t take it too far), especially, that have turned out to be useful to me so many times that I’m certain that judicious application of some of the other GoF patterns would be just as useful should I ever come across the need.

    So it’s not complete bullshit, and it’s not the be-all, end-all of programming, either. As with most things, it goes right down the middle.

    Comment by Kenneth G. Cavness — October 15, 2003 @ 6:30 pm

  2. See, the scary thing is that: 1) the idea of design patterns was startlingly new when the original GoF book was written, and that prior to that, those patterns were all just things that individual programmers learned on their own or picked up from experienced programmers, and 2) the GoF book was written eight years ago, and only started getting really popular (in my experience, anyway), in the last two.

    No, that’s not the scary part, come to think of it. The scary part is that when it was written, the very idea of object-oriented programming was still controversial as all heck. And, oh yeah, even today, you’ve got people like Joel Spolsky missing the point on exceptions vs. return codes.

    Computer science, as an engineering discipline, is about where physics was before Newton or economics before Keynes.

    Comment by Mike Kozlowski — October 15, 2003 @ 6:31 pm

  3. I’ve started to find that (C++ world) Loki and Boost are to design patterns what STL is to container implementation. When you start using a nice standard tool, you don’t have to think about your design anymore.

    In fact, the more I use Loki and Boost, the less I have to use STL itself. I can’t wait until these things make it into C++ standard.

    Comment by alex — October 15, 2003 @ 10:13 pm

  4. Patterns provide a common vocabulary to aid in communication of (programming) cliches. All of the truisms about not getting lost in the carpentry details carry over pretty well from Alexander’s original domain, I suppose.

    The GoF has a focus on object-orientation, which is fine and all, though you could reasonably implement most of those patterns in languages with imperative or functional bents. (And I suspect that most of us have.) You might be familiar with other cliches from those programming traditions, like “vtable” or “currying” or even “skidmark”. The GoF book, and other books like it, are a fine way to hone your understanding of a given pattern — maybe like a yoga book with a few pages on each of the classic poses; I don’t read yoga books, though, so maybe rather _unlike_ that.

    I don’t know what “Pattern Programming” is, or how it would be meaningfully distinguished from non-Pattern Programming. If you’re programming, you’re almost certainly writing a fair bit of code that brushes up against many common patterns. It might be that your implementation isn’t quite as robust as some Canonical Visitor In C++, and so you’ll take it on the chin WRT exception-safety or STL-friendliness. It might also be that by breaking one of The Rules in your Wrapper, you can make it fit your design requirements better. Nice to make that sort of decision consciously, and with the benefit of whoever’s previous experience, rather than just stumbling through it. (Or, I find it nicer to do; I wrote a lot of shitty almost-patterns before I realized that reading about software — and reading source — could make writing software easier and more pleasant.)

    The idea that Patterns will make your teeth whiter and improve the performance of your RRSP is, obviously, nonsense. But when I’m reading code and see a comment that “this is basically a Visitor over each of the registered protocols, to frozzle their fribbles if they match the provided warble”, I can absorb that section a lot more quickly than if I have to figure that out myself.

    And once you have a well-established grammar/pattern language/etiquette/heraldry for whatever it is you’re doing, you find your attention drawn to the parts that _aren’t_ done in The Usual Way, which tend to be the parts that you’re going to be debugging in a week.

    Whatever your feelings on Patterns (or XP, another programming trend/fad/option that’s seen some coverage hereabouts), if you don’t find something interesting over at the Portland Pattern Repository, you’re not really trying. It’s as bad as Citeseer for losing afternoons and weekends.

    Comment by Mike Shaver — October 16, 2003 @ 2:45 pm

  5. Furthermore, please don’t be painting the entire industry with the brush that you dipped in your faculty’s toxic and clichéd enthusiasm. Are you seeing this sort of reckless devotion to Patterns throughout softwaredom? (I see it in some places, but I wouldn’t consider it epidemic. There is some great Anti-Patterns literature out there as well, in fact.)

    Comment by Mike Shaver — October 16, 2003 @ 2:48 pm

  6. Once again, I sense the enormous difference between what I’m being told at school and the way things actually are.

    I promise, I will learn this soon.

    Comment by Mike Hoye — October 16, 2003 @ 6:58 pm

  7. Just make sure you don’t also lose sight of the difference between the way things are and the way they should be!

    Comment by Mike Shaver — October 16, 2003 @ 10:33 pm

  8. Re the school/reality divide: One of the things I’ve found is that it’s difficult to appreciate a solution unless you’ve repeatedly banged your head against the problem. To take a literally elementary example, I wouldn’t have been so amazed at the power of arrays when I discovered them in fifth grade if I hadn’t gotten so frustrated writing variable names like SCORE1$, SCORE2$, and SCORE3$.

    Comment by Mike Kozlowski — October 17, 2003 @ 9:06 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress