Web 2.0 Blog Logo

The Beta Culture… and Gammas

This has been blogged about many times in the past by many different bloggers and surely goes to show the extent to which The Beta Culture has invaded the Web, and more specifically the Web 2.0. So why has this term, previously consigned to testers and developers, suddenly become such a big part of the Web?

There has been some speculation as to why many of the “new” web applications have launched bearing the Beta moniker. There has even been some critiscism, which I believe has been misplaced. In order to fully understand the reasoning for this you have to examine the way the development process has changed for this new breed of Web 2.0 applications.

At this point I should point out that I am familiar with the traditional software development process. In fact, as part of my day job I form a key part of that process. As many of you are aware, the standard doftware development process represents an iterative process of Analysis, design, development and testing. Each one can go through a number of iterations and in many cases the interim builds will never see the light of day. With a web-based application however this is no longer a feasible approach. In fact the testing phase has been almost entirely shifted out of house. This essentially allows all the users of the system to be beta testers. A role previously reserved for specially selected volunteers.

The obvious benefit to the application provider is that they don’t have to commit a huge amount of effort into testing. I’m not suggesting that we are using untested applications but it is more likely that any testing that takes place will be Unit Testing and carried out by the developers. The real testing is completed by the Beta testers, i.e us. The shift in development effort isn’t limited to the testing phase either. If you look at many web applications you will notice minor changed are being made at regular intervals. And I’m not talking about weekly or even daily changes, there was a recent quote that a certain high profile web application releases new builds at up to half-hourly intervals. Can you image Microsoft releasing a new path for Windows every half hour? Of course not, its not feasible, but because of the method of distribution when dealing with web applications it is entirely possible. Think about it, every time you load a web application, you get the very latest version. Not only does this allow for frequent, incremental releases but it also reduces the cost of releasing a new version. In fact, if the processes are clearly defined and tested then the cost of releases could reduce to near nothing (taking into account that time = money and it will require someone to merge builds, compile, release etc).

Functional Testing

One of the dangers of this method of development is the chance that a fault can arise that affects the operation of the rest of the service. There is a way of negating this risk to a certain extent, however. The chosen method involves controlling the release of a new build and restricting it to a chosen set of users. In some cases this is controlled by having groups of users but in many cases it simply involves randomly selecting a group of users to distribute the new release to. This was an approach recently taken by Yahoo where they selected a range of IP Addresses to roll out the new front end to. A similar approach has been taken by Yahoos perennial adversary in the search engine wars, Google.

In order for this approach to be successfull you are almost entirely reliable on your user base to provide feedback. By extension you are also reliant on the systems you provide for feedback. If you look at one of the stars of the Web 2.0 revolution, flickr, you will no doubt notice that at the bottom of every page there are numerous links. A large section of these are ways in which you can interact with the team behind flickr through forums, emails and support requests. There is also the ability to report bugs and suggest new features. Luckily, one of the cornerstones of the Web 2.0, collaboration, helps create a community which is keen to see their toolset grow and remain a stable way of growing their relationships. This means that the community is usually a reliable source of feedback for these applications.

Summary

I hope its all clicked into place by now. Unlike traditional software development, where Betas were closely controlled releases given to a set number of users, they have become a mechanism that allows organisations to speed up the entire development process and shift a significant amount of effort outside their organisation. I would suggest that the Beta moniker in the world of Web 2.0 actually isn’t the same as Betas in the world of traditional software development. In fact, given the tradition of using the greek alphabet I would suggest that these releases are actually Gamma versions. A beta release of these applications would better describe the closed feature-based releases as seen in Yahoo and Google. The Alpha releases would then become the internal, or very closely controlled (closed releases, but not in the sense Gmal was closed) releases prior to wider public adoption.

To me, these Gamma releases reflect the constantly evolving nature of these applications. It would aknowledge the fact that these release do not have a mirror in the normal software development world and are almost unique to the medium, development process and distribution methods of the internet and more specifically the Web 2.0. It would also allow application providers to drop the Beta tagline which currently does a dis-service to the current state of the tool and the effort that is being expended to keep the services evolving.  Its easier to keep an application in a steady state than it is to maintain a constantly changing state, especially where a certain level of stability is expected.  I hope this explanation goes some way to address the concerns of the Beta-Bashers amongst us.

This post was written on Sunday, April 9th 2006 by Simon T and has been categorised under Opinion , Technology , Web 2.0. The trackback URL is here or you could add a response. If you really want to you can Digg Story or add it to del.icio.us, Technorati Cosmos, Blinklist, furl or Reddit.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>