General-Purpose Systems in the Age of the Long Tail

Imagine a tool that does lots of things, and another that does one thing really well. And imagine both of them are free. Long Tail theory suggests the specialised tool wins, right? No, maybe not. If the general-purpose thing does an okay job, many will prefer it instead. Why? Because there’s a premium attached to things that are predictable – if you’re already familiar with the general-purpose tool, because you’ve used it or heard about it from a trustworthy mate, you’ll probably try it first.

All this is the topic of Dan Bricklin’s new essay, When the Long Tail Wags the Dog. Examples he cites are spreadsheets (of course :-), word-processors, PDAs, email, cell phones, and cars. All of these products have more specialised substitute products available, but the general-purpose systems have prevailed because people are often more willing to bend them into the things they want, than enter the land of the unknown. You might not like KFC very much, but you attach a premium to it because you know exactly what you’ll get.

Quiz: What Does URI Stand For?

I got bitten with this in the RESTful Services pattern.

What does URI stands for?

  • (A) Universal Resource Identifier
  • (B) Uniform Resource Identifier
  • (C) Universal Resource Indicator
  • (D) Uniform Resource Indicator

The most up-to-date answer is actually the second choice above – it’s the title of this RFC. But the RFC explicitly mentions an earlier paper which uses the first choice.

So it seems that “Universal” shifted to “Uniform”, but “Indicator” has always been plain wrong.

I Was Referred to AjaxPatterns.org

Image Hosted by ImageShack.us

I had a funny story the other day: Someone referred me to Ajax Patterns.

While researching a number of patterns, I contacted relevant developers for their take, as reflected in the pattern-specific acknowledgements. I have to say I’m very grateful for everyone’s help and most people have given me plenty of detail. While researching one pattern some months ago, I mailed a developer about some work he’d done (dang, did I just give away this anonymous person’s gender?). I didn’t hear back, which was fine as I know most people are busy and most of us (certainly me) let emails fall so far down our inbox that we forget it’s there.

Anyway, the other day I got a polite response apologising for the delay and referring me to the pattern in question, ajaxpatterns.org link and all! The same pattern I had been researching when I sent the original email! In further correspondence, he took it in good humour and said “Now you know that I’m pointing to your site as the authority on <pattern name> :-)”.

Ajax Lite Versus Ajax Deluxe

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a desktop in that the browser is driving the interaction – it mediates all interaction between the user and server, so there are no – or few – direct page refreshes. Similarly, there’s no – or little – session tracking in the server, because all relevant state can be managed inside the browser. The server may not know about HTML at all, and just offer generic web services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall, but one that’s been sprinkled with Ajax here and there. For instance, Ajax might be used to validate a form before it’s submitted using standard form submission, or to reveal some instructions on the page when a user requests help. An example is Delicious, which works fine on legacy browsers, but offers Ajax Suggestions for the many browsers that support it.

Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally lead to a nicer, more effective, user-interface. It also facilitates a well-partitioned architecture, since the presentation logic can be isolated inside the browser and the business logic isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be “turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.

Ajax Lite Versus Ajax Deluxe

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a desktop in that the browser is driving the interaction – it mediates all interaction between the user and server, so there are no – or few – direct page refreshes. Similarly, there’s no – or little – session tracking in the server, because all relevant state can be managed inside the browser. The server may not know about HTML at all, and just offer generic web services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall, but one that’s been sprinkled with Ajax here and there. For instance, Ajax might be used to validate a form before it’s submitted using standard form submission, or to reveal some instructions on the page when a user requests help. An example is Delicious, which works fine on legacy browsers, but offers Ajax Suggestions for the many browsers that support it.

Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally lead to a nicer, more effective, user-interface. It also facilitates a well-partitioned architecture, since the presentation logic can be isolated inside the browser and the business logic isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be “turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.

The Contractors Who Waste Time

Carlos Viellas has been watching contractors waste time (emphasis mine):

As I see it, there are two positive incentives: peer pressure in justifying rates, and collecting good contacts and references. In the situations we have been witnessing, those pale next to doing whatever is possible to extend the contract, which more often than not are some incarnation of finger-pointing, back-stabbing or just plain inaction in order to make the project as late as possible. By extending the contract, they can ensure there’s always time to fix the mess created by blaming everyone else but their contracting buddies (those who’ll happily point them to new gigs) and pretending to work harder than everybody else by assuming authorship of other people’s work and ideas, while happily surfing the web all day.

Actually, there’s another positive incentive: Good contractors enjoy doing a good job. Not for contacts or references, but because they just like what they do. I’ve been fortunate to work alongside people like this and they are often highly productive precisely because they want to be productive. As it happens, there’s a very different risk here – if there’s too much obstruction, too much politics, they’ll be the first to leave.

Under good project leadership, time-wasting contractors shouldn’t be recruited, and those who slip through shouldn’t last very long.

Detecting time-wasters during recruitment:

  • Check references (amazing how rarely this happens, maybe something to do with HR policies in many places that place a gag on non-HR staff giving references).
  • Look for genuine interest in software development – hobby work, professional groups, presentations, conferences attended. If they’re not really interested in these things, they probably won’t be motivated to do a stellar job on your project either.
  • Education and experience. It would be nice if you could learn “Information Security in 60 minutes or less”, but, well, you can’t. I think this is relevant to time-wasting because there seems to be a correlation. (Recent podcast with AT&T’s Ed Amaroso touches on this topic.)

Detecting time-wasters during development:

  • Daily Scrum meeting or equivalent. And if people have problems, take them seriously and deal with them.
  • Task estimation at an appropriate granularity, e.g. tasks of several days.
  • Encourage at least some pairing.
  • Real leadership.
  • Collective ownership, or at least ensure some people know the entire code base so you can ensure work is reasonable.
  • Avoid micromanagement. Nothing will destroy morale faster.
  • Moreover, keep people motivated to avoid time-wasting in the first place. (That’s a separate post.)

The Contractors Who Waste Time

Carlos Viellas has been watching contractors waste time (emphasis mine):

As I see it, there are two positive incentives: peer pressure in justifying rates, and collecting good contacts and references. In the situations we have been witnessing, those pale next to doing whatever is possible to extend the contract, which more often than not are some incarnation of finger-pointing, back-stabbing or just plain inaction in order to make the project as late as possible. By extending the contract, they can ensure there’s always time to fix the mess created by blaming everyone else but their contracting buddies (those who’ll happily point them to new gigs) and pretending to work harder than everybody else by assuming authorship of other people’s work and ideas, while happily surfing the web all day.

Actually, there’s another positive incentive: Good contractors enjoy doing a good job. Not for contacts or references, but because they just like what they do. I’ve been fortunate to work alongside people like this and they are often highly productive precisely because they want to be productive. As it happens, there’s a very different risk here – if there’s too much obstruction, too much politics, they’ll be the first to leave.

Under good project leadership, time-wasting contractors shouldn’t be recruited, and those who slip through shouldn’t last very long.

Detecting time-wasters during recruitment:

  • Check references (amazing how rarely this happens, maybe something to do with HR policies in many places that place a gag on non-HR staff giving references).
  • Look for genuine interest in software development – hobby work, professional groups, presentations, conferences attended. If they’re not really interested in these things, they probably won’t be motivated to do a stellar job on your project either.
  • Education and experience. It would be nice if you could learn “Information Security in 60 minutes or less”, but, well, you can’t. I think this is relevant to time-wasting because there seems to be a correlation. (Recent podcast with AT&T’s Ed Amaroso touches on this topic.)

Detecting time-wasters during development:

  • Daily Scrum meeting or equivalent. And if people have problems, take them seriously and deal with them.
  • Task estimation at an appropriate granularity, e.g. tasks of several days.
  • Encourage at least some pairing.
  • Real leadership.
  • Collective ownership, or at least ensure some people know the entire code base so you can ensure work is reasonable.
  • Avoid micromanagement. Nothing will destroy morale faster.
  • Moreover, keep people motivated to avoid time-wasting in the first place. (That’s a separate post.)

Ajax Patterns in the Pattern Community Radar

I’m pleased that AjaxPatterns.org seems to have entered the pattern community radar in the past couple of months (or maybe earlier, but that’s the impression I’m getting) …

Workshop on Ajax Patterns

Ralph Johnston (of GoF Design Patterns fame) runs a regular patterns reading group/workshop and they’ve been looking at the Ajax patterns. Fortunately, they release the discussions online, which is a great, if unexpected, source of feedback for me! (I had some volume issues and need to listen again after pumping up the MP3s, so I won’t comment on the content yet). The discussion is a mix of general Ajax talk (most participants are approaching this as Ajax programming newbies) and critical analysis of the patterns.

  • Directory of all pattern workshop MP3 (where I assume you’ll find a second workshop too in a few weeks).
  • Direct link to the discussion: http://brain.cs.uiuc.edu/SAG/2006-01-30-Ajax.mp3
  • (which I won’t link to directly because a future version of WordPress might incorporate it into my podcast feed :-).

Brian Foote: Calling a pattern a pattern

(I’m using this as a springboard to rant on some general pattern stuff …)

Pattern veteran Brian Foote (also in the discussion above) says that JJG’s definitive Ajax article is “quite pattern-like” and apparently concurs with James Governor’s assertion that Ajax is a pattern. Of AjaxPatterns, he says:

Now, Michael Mahemoff has exhibited no compunction in calling a pattern a pattern. Ralph Johnson pointed out this website a few weeks ago for a forthcoming book on Ajax Patterns. It is tastefully rendered, and quite engaging. I commend it to the reader’s attention.

Yes, Ajax has always been a pattern to me. In the notes for last April’s Ajax podcast, I referred to it as an “architectural style”, which I use synonomously with “architectural pattern” (other examples would include “MVC”, “Blackboard”, etc; I think I originally got this idea from Buschmann et al’s System of Patterns V1). A few months ago, I bit the bullet and added an “Ajax App” pattern to AjaxPatterns. Not all pattern languages need a root, but it makes sense in this case to have something that ties everything together.

Is “Ajax App” a pattern? I say it is because it’s a well-proven solution to a recurring problem. Some say that patterns should provide some insight, and Ajax App is just too obvious a solution nowadays to call it a pattern. It would have been fine for JJG to introduce “Ajax App” as a pattern in early-2005, but what’s the value of an “Ajax App” pattern in the enlightened era of early-2006? I would mostly agree with that if the “Ajax App” were published in isolation. But it’s not. It’s published in the context of 68-odd patterns on all things Ajax, as the pattern that holds them together, and many of the patterns refer back to it. It’s a high-level, architectural, pattern, which can be decomposed into lots of smaller patterns that are also documented. It has the essense of being unobvious, even if the buzz of the past year now renders it obvious.

Another way to say it: I’m not really comfortable with the argument that patterns must be unobvious. In some contexts, there’s still many benefits to gain from using a pattern construct to document something that may actually be obvious. I emphasise this because it not only explains why “Ajax App” is a pattern in AjaxPatterns, but also XMLHttpRequest Call, Display Morphing, etc. They are obvious things to do because they fall out directly from the technology … What else are you going to do with an XMLHttpRequest but issue a call??!!!! But just because they are obvious, doesn’t mean we can’t document them. They completely integrate into the structure of the overall Ajax Patterns language, with lots of useful links to and from them. They can completely be described by the standard pattern notations. They give us a suitable, distinctly named, easily discovered, container to elaborate on the technologies involved, the decisions you have to make, and so on. Which is why you’ll find XMLHttpRequest’s API in the XMLHttpRequest Call pattern, and an overview of the DOM in the Display Morphing pattern.

For the record, I’m also not comfortable with the argument that patterns must be proven. Again, I think the argument for provenhood comes from a well-intentioned attempt to keep the patterns relevant and useful. But I’d rather lay out all the patterns on the table, present whatever evidence exists, and let the reader decide how they stack up. For that reason, you have some patterns like Host-Proof Hosting that are unproven, but promising enough to point out. Again, they fit right into the structure, they are easily documented with a standard pattern structure, and they are a suitable easily discovered namespace to elaborate on the concepts as well as facilitate a discussion of whether it’s worth implementing, and

I’m not a “pattern theoretician”, so these ideas perhaps don’t hold up to current thinking. I discovered early on that the patterns community generally avoids too much meta-discussion on patterns and I’ve always respected that view. My PhD never defined a pattern as a “vector of fields 1..n” or a pattern language as a “directed, acyclic, graph”, even though some academics felt it would have been the right thing to do. I take a pragmatic view of patterns – “Are they useful or not” is really my main interest, and I think that’s reflected in the comments above. I don’t mind if you call “XMLHttpRequest Call” a “guideline” instead of a “pattern”, but I think you can see why I choose to call it a pattern – it’s documented that way and it happens to live within a larger system of patterns.

All this comes down to fuzzy thinking instead of strict dychotomies – the same reason I often talk about “how Ajaxian” a system is, rather than “Is it Ajax or not”. Same for a pattern – “how pattern-like is it” rather than “Is it a pattern or not”? I find strict definitions futile, which is why you’ll usually find me disclaiming and apologising profoundly whenever I utter one.

Erich Gamma

From Brian Higgins:

I’ve been working on some Ajax stuff lately and this morning I was complaining to patterns guru Erich Gamma that I hadn’t seen any good design pattern resources for Ajax. He pointed me to this site which looks good: http://ajaxpatterns.org/ Would have never guessed that one!

Interview with Wally McClure

Not specifically patterns, but I also want to point out that Wally McClure from the ASP.Net Podcast recently interviewed me (fortunately for me not about ASP.Net, which would have been pretty brief!). I’ve had various mail conversations with Wally, who’s writing a book on Ajax and ASP.Net, so it was good to catch up and talk Ajax. Unfortunately, we had some skype issues, so we didn’t end up talking too in-depth. (BTW Both Wally and I had Skype issues. Is Skype seriously ready to be the telephone platform for the next decade? Seems way flakey and lacking in support to me! I submitted a detailed error report a while back and received nothing, despite the fact that I pay around $50 a month for calls. The error message is something about an unauthorised resource, as I recall, which a lot of googling tells me is a file permission error, perhaps, but Skype’s log contains zero information about the resource in question even though people have been experiencing the problem for a year or more.)