That Giant Sucking Sound is Ajax Turning Your Site into an Application

Dietrich Kappe, Friday, October 27, 2006 @ 9:30 am

I have a simple rule of thumb for support costs: take the number of use cases, function points or whatever you use to estimate development effort, multiply it times the number of users who will be accessing your application, correct for the sophistication of that population -- Joe Hacker versus Grandma Moses -- and the amount of money that is on the line for both your users and your company, and voila! you have a three shift operations center and an army of developers wearing pagers. Actually, it gives you an order of magnitude figure for the kind of effort supporting your application will take.

Here it's common to distinguish between sites and applications. By sites we usually understand the simple content display where your use cases consist of browsing, search, emailing an article to a friend and viewing an article in printable form. Four use cases, give or take. Add in the occasional submission form, and your support team, such as it is, barely needs to break a sweat. Applications, if I may state the blindingly obvious, have many more use cases and thus much greater support costs.

Now at what stage does a site become an application? This is sort of like the riddle of Theseus' ship. (Theseus was the guy who slew the Cretan Minotaur.) His ship was preserved as a memorial. As planks and other wood rotted, it was replaced bit by bit until not one piece of the ship was original. Was it still the same ship? If not, at what point did it stop being the same ship? Fortunately for us, our question is not quite as hard. Ours is not a question of identity but of degree. A site doesn't magically become an application with one additional use case, it just becomes more complex. In fact, our distinction earlier between sites and applications was a false one -- a site is a simple application, with a simple purpose and simple task flows.

Now I started this post talking about support costs and ended up talking about wooden planks. My point is that as you go about replacing the rotted postback planks in your site or application with nice new pressure treated Ajax planks, keep and eye out for feature creep. Are you adding functionality to your site? Are you adding digg style voting to your content? Are you adding a portal so users can customize their experience? I'm not saying don't add them. By all means, take advantage of the opportunities the technologies give you, just be cognizant of any new features and use cases you add. You could find yourself sucked from the relatively safety of the content application -- or "site" -- to the deep water of the full on application.

When they pry the support pager from you cold, dead hands, you'll go to that Valhalla that is home to optimists, jaywalkers, chronic underestimators, and managers that think that product launch is the finish line.

Technorati : ajax, editorial

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   If you’re interested in low-latency application services with a scalable back-end using ajax/comet transport, I suggest checking out rphd.sf.net, the Ajax/Comet Request Router.

   Comment by Aminorex, Sunday, October 29, 2006 @ 7:58 pm

Leave a comment