"Perpetual beta" means never having to say you're sorry.

Most of what I read under the "Web2.0" moniker just goes over (or is it under?) my head. But the other day I was on a telephone discussion listening to the characteristics of "Web 2.0": "collective intelligence", "mashups", "light weight programming", "perpetual beta". "Perpetual beta!" That caught my attention. I'd heard it before, but hearing it this time made me think about it, and, well, I have concerns.

Perpetual beta means newer technology sooner. It's 2006; who wants to wait for anything these days? I used to believe that I was as game as the next person when it came to new technology, but I'm getting jaded. Maybe it's the increasing amount of time it takes to figure out how to use new technologies. With all the hoopla about usability and information architecture I'm starting to expect applications and websites to be easy to use and, well, I'm not feeling the love. Maybe I'm just not finding the right sites. Years ago, a colleague from Xerox PARC, a UI expert, told me why he hated Unix: "Each command has its own syntax". I'd been a Unix lover for years, but had to admit that he had a point. And I feel the same way about web applications. Sometimes the important links are found in drop-down boxes on a bar across the top; sometimes they're in a column on the left (or right); sometimes they're in a set of lists along the bottom of the page. Are we having fun mousing around, demonstrating Fitt's Law? I was totally flummoxed trying to find how to add contacts on Flickr; I thought all those links at the bottom were just the usual boilerplate site and company info. As a result I kept inviting people to join Flickr rather than adding a Flickr user as a contact. Was my experience simply a "user error" or an application design flaw? Well, maybe it's both. But usability is a comparative term, and no matter what metrics we devise to measure "ease of use", it's going to take some time to figure them out. Hey, maybe perpetual beta means that we'll be figuring them out forever.

Perpetual beta means yesterday's features are, well, just so "yesterday". I'm happy to check out new features (at least I want to think I am). But I want to do that without breakdowns in usability and my own work practices. I want to keep working, not learning how to work the technology. But, see, there's the rub. I want to be using the latest software, but I also want to rely on the software I use. I don't want to worry about security; I want software to be secure. I don't want to cross my fingers when I install updates, and I don't want to spend time re-setting my preferences. And I really don't want to deal with unexplained program errors. Bill to software applications: thanks for helping correct my obvious errors (empty data fields, incorrect e-mail syntax, etc.). But stop with the Java stack traces and unexplained errors that result in sudden terminations of the program and of my work.

Perpetual beta means never having to release finished code. Now I know why there are so few software releases with version 1.0 or higher. If I release a 1.0 version, that's a major release and implies that the software, application, system, or web service, is ready for production use, and people can rely on it. And I'm on the hook for support. Whoa, that's kinda scary. I was nervous when I released a version control tools to a development group responsible for a commercial "411" telephone information system. People depended on that software, and I had to insure they could. It took confidence in the code, the documentation, and a commitment to delivering software that worked as documented. I made sure the software behaved as documented before I released it. Yes it took time, but it was software capable of production use.

If the Web 2.0 future is about continual software updates and additions of features then what's needed is a base that can support changes and remain responsive, reliable, and resilient in the face of errors. This base needs to be designed and built to production level standards. It can't be beta software; it needs to be engineered software (designed, constructed, and tested) and released with measurable, confirmable, and supportable qualities of security and performance. My concern is that a perpetual beta mindset allows developers to release software without making any commitment to support the needs of the users. I can live with simple features and incremental dellivery of software , but some part of this new distributed and component-based system of web services and applications needs to have supported performance guarantees. Web 2.0 might be about perpetual innovation, perpetual upgrades, and perpetual improvement. But the released software needs to provide perpetual usability, perpetual reliability, and perpetual security. It has to be better than beta-level software. And developers need to make production level commitments.

Technorati Tags: , , , , ,

1 Comment

For what it's worth, our group (The Podcast Roundtable) talked about beta software practices in the discussion podcast we've now posted here: