Defining Design Patterns

My friend and colleague, Paul M. Jones, calls me out as a bully. Apparently from the way interviewees complain to their headhunter about me, I am.

Like W after 2004, and fully intend to use this new capital accumulated by my just-annointed “bully-mandate” to tell him (and the interviewees) off as being sore losers who can’t handle the new asshole I tore in their shit last night. ;-)

In the real world, when a candidate fails to answer a question, I say, “Don’t worry. It’s okay,” and move to a different topic area as I have lots. I’ll also point out that none of these candidates actually were around when I gave my evaluation. They’d see that the only trouble they get into is if they lied to me or express something wrong with absolute confidence. Those show a lacking the ability to be able to work well in teams or learn new things. The question is designed to test those qualities in a candidate—not whether they can recite some book definition of a design pattern.

Okay, fine, but what about Paul who stands up to The Great Bully? Well let’s get down to the nitty gritty of defining (programming) design patterns…

Three Wise Monkeys
Three Wise Monkeys
District Bar, South of Market, San Francisco, California

Nikon D3, Nikkor 24-70mm f/2.8G
f/2.8 at 1/50 sec, iso 12800, 29mm (29mm)

Paul’s argument

Paul’s first argument centers around my definition if design patterns. I say that it’s hard to define them but “you’ll know it when you see it.” He then references Martin Fowler’s definition which is actually cribbed from Christopher Alexander’s definition which is…

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

He then says the actual definition depends on the problem domain. Then gives his definition as: common vocabulary to aid communication.

He disagrees with me that an algorithm (like quicksort) and best practice (like code versioning) are not patterns. Instead, he states that they are different sort of patterns, just not application design patterns.

Finally he goes into a rant on how I’m an intellectual bully. :-D

Finally he calls that my discourse is uncivil.

Watch me dodge like Bubba Clinton…

I shall do forthwith.

A brief history of the design pattern

I am well aware of Martin Fowler’s book. But unlike Paul, I’m going to provide some missing historical context.

The book in question is Patterns of Enterprise Application Architecture by Martin Fowler, chief scientist of ThoughtWorks, one of the premier Enterprise software consulting firms. This book basically introduced design patterns to web development, but it contains numerous pitfalls that have set the web world back as much as it has advanced it.

However the quoted part in question is actually a copy of the Gang of Four book, which attributes their influence to the Christopher Alexander work.

This is the architecture of building, not software design here!

If the definition of patterns is “domain-specific” then wouldn’t that imply that my definition of: you know what a design pattern is “when you see it” is exactly right? I mean here we find design patterns in the architecture of buildings, in the design of cities and towns, in object-oriented programming, in enterprise web development, and in web page design.

Apparently the definition of design patterns are “so meta.”

Going back to the original definition of “you can use this solution a million times over, without ever doing it the same way twice” that the definition is quite recursive, because apparently I can use the term “design pattern” a million times over across an infinity of application without ever using it the same way twice! How then are we to define it?

Defining a design pattern

My point is the nature of a design pattern is to defy direct definition because its meaning is determined by context in the same way the meaning of “pornography” depends on the common social values of the time.

Yet even though there are these context-dependent differences, there are still commonalities. Societies may disagree on whether or not the uncovered face of a woman is “pornographic,” but almost all of them agree that pre-pubescent children in sexually explicit acts would be!

The commonalities? Paul conveniently stops quoting me right before this part:

But [design patterns] do have these qualities. The first thing is, it has a name. You have to give it a name or it isn’t a design pattern. Why? It is a vocabulary—when I speak to you, I could write it for you; or I could give it a name and you could write it for me. You see, I’m an architect and I don’t like to code so this stuff really helps! The second thing is it indeed does solve a problem. The third thing is it’s independent of the code that implements it. But the last and most important thing is—that separates a design pattern from what we would call a “best practice” is—it has consequences.

Hmm, that seems very constructive to me. Even though I can’t define design patterns: I offer four commonalities that I’ve found in every definition of a design pattern in every field:

  1. vocabulary
  2. solves a problem
  3. implementation independence
  4. has consequences

Now you can get to this in different ways: if you said, “the right pattern to use depends on context”, that covers (4). If you said “you never use it the same way twice,” that covers (3).
Paul’s definition covers (1) and I assume he imputes (2). That’s not bad, actually, the vast majority of candidates asked this question give me an answer like this: “It’s something that solves a problem” (2) if they get that far!

Now remember, I don’t ask this question to ones who don’t list design patterns on their resume. These are people who actually claim to be experts in design patterns and can’t even give a definition that contains or infers more than one of those aspects essential in the definition of **all** design patterns!

The problem with quicksort

Are algorithms patterns? Well, I guess an argument can be made that they are. In interviews, I’m not interested in right or wrong but in how the candidate reacts to open-ended questions that allow flexibility in interpretation.

Let’s assume algorithms like quicksort can be patterns. Well here is the wikipedia entry of algorithm:

In mathematics, computing, linguistics and related subjects, an algorithm is a sequence of finite instructions, often used for calculation and data processing. It is formally a type of effective method in which a list of well-defined instructions for completing a task will, when given an initial state, proceed through a well-defined series of successive states, eventually terminating in an end-state.

You see the problem here I hope. Algorithms are a mathematical construct that is “well-defined” this runs in direct confrontation to the definition that Paul Jones quoting Martin Fowler (quoting Eric Gamma) quoting Christopher Alexander gave: “the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

I hazard to guess that this implies that in the context of computing, quicksort cannot be design patterns by definition because the former’s solution looks the same way every time!

I’ll admit I can be wrong here, but I believe I’ll have an easier time getting Martin Fowler, Eric Gamma, and Christopher Alexander to side with me over Paul on this one. ;-)

Considering consequences

This deserves further expansion, but ask yourself why do we find implementing “Hello World” in 160 lines of object-oriented PHP code “wrong” and anti-patterns humorous?

Clearly that’s where the “in our environment” segment of the quoted definition comes from. But it’s a stretch unless you understand the original context. This alluded to in the Wikipedia entry on design patterns (emphasis added):

Christopher Alexander describes common design problems as arising from “conflicting forces” — such as the conflict between wanting a room to be sunny and wanting it not to overheat on summer afternoons. A pattern would not tell the designer how many windows to put in the room; instead, it would propose a set of values to guide the designer toward a decision that is best for their particular application. Alexander, for example, suggests that enough windows should be included to direct light all around the room. He considers this a good solution because he believes it increases the enjoyment of the room by its occupants. Other authors might come to different conclusions, if they place higher value on heating costs, or material costs. These values, used by the pattern’s author to determine which solution is “best”, must also be documented within the pattern.

Christopher Alexander is basically stating, flat-out, that it isn’t a pattern if doesn’t have some sort of tradeoff.

Here is the definition of a best practice:

Best practices can also be defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people.

Compare that to the definition above and you’ll notice that, unlike a best practice, the concept of “best pattern” depends on the context (or values) of the problem and is open to interpretation.

Here is section of Alexander’s book that might be relevant:

The pattern concept can usefully be contrasted with the idea of a rule. A rule indicates what is to be done in a given situation. A pattern raises issues that may need attention and provides ideas and examples of what could be done to address them. Thus, while a rule bypasses people’s intuitions, a pattern calls upon these intuitions and attempts to educate and strengthen them in the process of solving the problem.

Programming is a creative occupation which requires refined intuition, in contrast to the idea of a rule (or best practice, or algorithm).

Anyone is free to ignore consequences, but they ignore them at their peril. Just as writing software is about making choices, so too making choices without examining consequences is not (good) programming. Or perhaps rather:

An unexamined choice is not worth making.

I’ll defend my bully nature in a future post. I will mention here, however, that I am apparently the self-proclaimed first “PHP Terrorist.” By definition, my discourse is going to be uncivil. But, I promise you I’m not indecent.

9 thoughts on “Defining Design Patterns”

  1. @Paul M. Jones: Corrected. It actually slipped in during an edit. I had Mr. Fowler’s name written a number of times and went to correct it in a number of places when I removed the whole thing for a later post. I then accidentally changed an replacement line back as William Fowler (the physicist).

    In the other four places in the article I had his name correctly as Martin Fowler. ;-)

    I did that once in the comments last year also.

  2. I think that Paul doesn’t like that you are douchebag, but a douchebag who happens to be right. He has probably had bad interview experiences, who knows.

    Speaking of interviews, you are bad at interviewing candidates. That’s because almost all people, especially programmers, are bad at interviewing candidates. We all tend to just identify people as being similar or dissimilar to us when we interview them. Of course we all think we are smart, so if somebody is similar then they must be smart too! For example, your interview questions present people with the kind intellectual problems that you enjoy. It’s easy to imagine an excellent programmer who does not enjoy such mental masturbation and responds with a rote answer that dooms her in her bid to join your elite cadre of PHP terrorists.

    That being said, I think that if you were interviewing Paul, you would hire him and likewise.

  3. I’d suggest that coupling a design pattern to the solution of a problem is kind of overstepping. I’d say that a design pattern produces a desired effect, or satisfies a condition. In this perspective, a design pattern could be thought of as equivalent to a syndrome, tecnnique, or diagnosis.

    For me a design pattern is an arrangement of elements and sets of elements, each having a known set of properties (a. k. a. interface), and meta-elements, such that one or more relationship(s) between the elements and meta-elements is established.

    Whether some of these are good and intended and other ones are bad and unintended consequence is not really part of the design pattern. For instance, economic inflation could be considered a design pattern.

    The fact is, as engineers, we label the behaviors we intended to create design patterns, and the ones we actually create as bugs. However, these are not really inherent in the design patterns as such, as much as they are commentary upon them after they have been applied.

  4. Why ask an interviewee for such an abstract definition of a design pattern in the first place? Why don’t you just ask them what the definition is according to Object Oriented software? Do you really care if they could tell you what it means in terms of bridge building or circuit design?

    Just because a candidate does not match your definition of a “design pattern” does not mean it is not a good definition. I think 1, 2 & 4 of your definition are good but personally I would not use the term “implementation independance” – it’s too abstract – you’d be hard pressed to implement the observer pattern in bricks and mortar.

  5. @Michael: I ask this question when a person put “Design Patterns” on their resume (about 1 in 10 candidates). Also the vast majority of candidates don’t even make it to my point of the interview—meaning, we filter out about 80% before I get to interview. I never claimed that my interview style is complete, nor even that good. However there is a world of difference between that and the claim that I “bully” candidates in an interview.

    Also, I wouldn’t be interviewing Paul since I know him personally. You don’t interview your own referrals and many people, each with their own style, interview a candidate. I will claim my interview style is unique. I will claim that hiring is very important and I take it very seriously. I will claim that while my style is no better than some, it is probably no worse than most.

    The simple fact is that about half the engineering hires have had to suffer my interview process. None of them have complained of being bullied (though many have complained about it being hard). And I still get into arguments with many of these hires on a great many things. But whether I’m right or wrong (most often I’m wrong), those arguments end in mutual respect. They are far from “like minded” with me.

    @Dave Edelhart: Almost all design pattern books (esp. the classic texts) finish the pattern with a section titled “Implementation” which describes a solution in a particular implementation of choice (for instance GoF does solutions in Objective C and Smalltalk, William Fowler uses Java, DHH uses Rails, Paul uses PHP). The issue I think you’re having with my concept is that the solution itself is independent of implementation. When defining a pattern we have to resort to specific implementations (solutions) to do so. This is like saying that a concept can be independent of language, but we still have to use words to describe them.

    If you had given me your second paragraph as a definition I’d say that it covers the “context/consequences” part and the implementation independence part, but that it’s missing the vocabulary part (I’ll grant that you’ve clearly implied this), and the solves a problem aspect (in the original definition, Christopher Alexander says, “describes the core of the solution).

    (There is an inherent misconception here that I expect candidates to answer more than 30% of my questions “correctly”—whatever that means. A question like this has no correct answer so that’d be sort of impossible. I’d be hard pressed to answer even my own questions “correctly.” More I’m interested if they can think about things and discuss things abstractly and concretely without have to resort to fallacious attacks, pandering, or an “I can look that up.”)

    I’m not sure that “economic inflation” would be considered a (macroeconomic) economic design pattern. While it is certainly a vocabulary and “occurs over and over again”, there is no “core of a solution” nor can this solution be implemented “a million times over, without ever doing it the same way twice.” Then again, I have a low view of macroeconomics so I’ll grant that I can be wrong.

    As for bugs vs. design patterns, I’d think intentionality is the key difference between them. There is a key word here in “design.” Bugs are not “designed” because if they were, they’d be features. ;-)

    In any case, all of that is far beyond the discussion of an interview session. And if this was the discussion I’d be happy because it’s clear that even though we disagree on some issues, you’ve though and can think critically about things. I feel (not know) that if the original definitions (Christopher Alexander, Gang of Four, or Martin Fowler) seem to take my side about the necessity of there being a “core of solution” somewhere.

    @Rob Graham: I simply ask them to define a “design pattern.” If you go to the followup article, you can see that I never received even the “book definition.” I believe the reason this happens is because the Object Oriented books never explicitly define “design pattern” (in OOP), but instead refer to Christopher Alexander’s work (in architecture and city design). I’ll grant that I may be wrong, but the first pages of both Fowler’s book and the GoF do this. And those two books are seminal in the field I’m hiring (web development).

    If you read that article (as well as the one above) you see I’m looking for 1-4 as “features”, not “exact wording” so the exact words “million times over, without ever doing it the same way twice” is just as valid (actually more so) as my term for that feature: “implementation independence.” I don’t use that because I personally find Christopher’s wording a little misleading in the field of engineering. In fact, when I refer to “design patterns” not in the ecumenical sense, but the specific OOP context: I say the words “language independence” and accidentally used that in earlier drafts of this article (you can look that up in Google if you don’t believe me) before I realized the error and changed it back.

    BTW, the fact that the candidate who doesn’t “match my definition does not mean it’s not a good definition” is the very reason I introduce the subject of design patterns with the tongue-in-cheek “you’ll know it when you see it.” as well as why this question gets asked in the first place. ;-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>