While on the Gillmor Daily during OSBC, towards the end of the show I expanded on a point that I’ve made before: that a big part of the equation that is Google is speed, pure and simple. Very low latency performance, delivered from their secret sauce architecture. I don’t mean to imply that a provider can deliver terrible search results or an awful application quickly and expect success, but speed – particularly as Software-as-a-Service (SaaS [1]) applications begin competing in earnest with their desktop counterparts – is a big, big deal.
The interesting thing is that speed is not traditionally considered a feature, per se. It’s a design consideration, to be sure, but in the applications I’ve developed speed has rarely been a part of the requirements gathering phase – apart from occasionally defining what consitutes unacceptable performance (greater than 8 second load times on web pages, for example). While emphasizing the importance of speed on Gillmor’s show, I acknowledged that users rarely consider speed as a feature as they might, say, the addition of Google Talk to Gmail.
But it’s becoming increasingly apparent to me that even if users don’t, developers should. While on the phone with a venture capitalist today, I asked what the date was for a particular event and in looking it up, he chuckled and said “I’m looking on my Blackberry because it’s faster than Outlook.” What was the number #1 requested feature for FeedLounge in the user voting? Speed. Why do I use Google Blogsearch? Because it’s fast.
As I discussed with the folks who attended the Search Mashups session at Mashup Camp moderated by DeWitt, high performance can in a sense dictate usage to a degree that relevance cannot. To illustrate the point, I related an observation that Christopher Baus had made when we were debating the value of tags, which was that, despite my position defending tags, he’d observed that at some point mid-debate I’d arrived at his site via Google, not my del.icio.us ‘Baus’ tag. The reason was simple: Google is much, much faster than del.icio.us. I value del.icio.us highly, don’t get me wrong, but if there are two routes to a resource – one through del.icio.us, and one through Google – odds are pretty good I’ll be taking the Google approach. What’s the best feature that del.icio.us could add for me, then? Speed.
In case it’s not apparent, let me be clear and say that I’m not talking about speed in any generic, bare-minimum sense – but the speed that Google, as an example, has mastered for search. The type of speed that, if you’re a technologist, makes you blink and say, wow, that was quick. The type of speed that for an ordinary user leaves no discernible impression whatsoever, except that they don’t mind using your application, and might even feel positively about it.
What’s the catch in all of this? Speed is [much] easier said than done, and depending on the application type might be near impossible for smaller players to deliver on cost constrained hardware platforms. But if I was putting together a service right now, it’d sure make my feature list.
[1] I’m not sure precisely when the industry settled on the term, but SaaS seems to be sticking. Good to see, not because of any particular fondness for that term, but because I prefer to a common lexicon to work from.
