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…

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. 😀

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.