… That’s the question I finally got to ask the man who gave Ajax its name, following Jesse James Garrett’s keynote last week at The Ajax Experience. I consider Ajax a very standard, uncontroversial, example of a pattern, so I’ve wondered why it wasn’t introduced as such, in the original Ajax paper.

Jesse said he’s asked the question quite a bit. He didn’t answer the question directly - there wasn’t a “Yes” or a “No”. Essentially, he just made the point that patterns mean different things to different people, everyone has their own idea, etc. In other words, I think he either doesn’t want to get bogged down in the debate or doesn’t consider it important.

At first, that seemed rather anticlimatic, but on reflection, I can see his point. He mentioned in his talk how people (of a certain kind, I guess) mail him saying “I wrote this app in 2000, it uses IFrame yadda yadda … Is it Ajax?”. So he probably has enough trouble with the definition of Ajax to worry about the definition of patterns as well. Moreover, he’s a consultant, and probably talks to high-level managers who wouldn’t know a pattern from a shell script.

So it’s understandable from a pragmatic perspective why “pattern” isn’t used in the original definition of Ajax, even though Ajax fits the mould perfectly. However, it is a shame for software, and industry at large, that patterns aren’t the standard way people think about designs and processes. Framed as a pattern, a high-level architectural style like Ajax can evolve quickly, as people begin to consider examples, forces, rationale, and all the other standard attributes of a pattern. Furthermore, people can ask about the role of this pattern in the entire ecosystem of patterns. What are its alternatives and how does it stack up? What are the lower-level patterns that should be solve questions opened up by applying the high-level pattern?

That many managers don’t get patterns leaves a lot of potential for improvement within organisations. An open wiki of interlinked organisational, technical, usability, etc patterns should be an asset to any company. As explained in this visionary paper by Jed Harris and Austin Henderson. The 2020 scenario suggests how patterns might be navigated in the future.

Then she puts a probe into the guise and begins looking for the patterns that the guise uses to model market response to Heavy Metal.* Her office shows her the internal organization of the guise as a network of nodes whose size and clustering reflect how much they contribute to the guise’s current display. Each of the nodes is a small view of the associated pattern, showing its current state; if she focuses on a single node, she can usually tell how it is contributing to the display. Olivia thinks of this display as a “sea of nodes” because the ripples and swirls remind her of flowing water. She swims through the sea, getting a feeling for how Fred has put the guise together, and how the guise itself is interpreting the current behavior of Heavy Metal’s customers. After a little while she zeros in on the service and support patterns. By suppressing the contribution of some patterns and looking at what changes in the display, she eventually finds a pattern— Service is a Feature— that seems to be most involved with the aspects that have been bothering her.