In Episode 5 of The Podcast Roundtable, my colleagues (Martin McKeay, Dan Sweet, Robyn Tippins, and Jeremiah Owyang) and I discussed, among other things, the current practice of wide public availability of “beta software.” My interest in this topic had been stimulated by reading this.
In the days of planned release schedules and successively more capable release functionality, the term “beta” was often applied to limited-release software where both distribution and user environments were tightly controlled and monitored.
Nowadays businesses are being built upon “beta” software that goes into universal web wide availability along with statements of incompleteness and limited support. Users are invited to use and write about the software. Users get early peaks at and access to useful features. Producers get real world feedback which helps further the development of future releases.
So what’s not to like about this situation, assuming that everyone understands that the software is “beta,” is not “finished,” and might be radically altered at a moment’s notice, thereby making any stored data potentially incompatible or unavailable?
Personally I believe that the benefits outweigh the costs if everyone understands what the process is. But I also understand why the process of "release early and release often" might be incompatible with some business models and management styles.
If you follow an "agile" project management philosophy applied to product development (see this Wikipedia entry for a summary of what I mean) you may believe that it is impossible to specify in detail what a finished product will look like and that a better approach is to develop and release early versions with usable functionality that clients - and customers - can react to. The idea is that, with development costs and times boxed in, the development, testing, and modification of multiple successive releases can have a more profound impact on overall project delivery performance than development based on a massively detailed initial design that everyone knows will change anyway.
Having been involved with projects that used this "frequent release" approach, I can see how the approach is applicable to situations where critical components of the overall delivery mechanism are already available. Using web and browser based delivery systems where application software and data can be delivered on a just-in-time basis, one can realistically think of delivering a useful product very early in the product development life cycle by adapting existing functionality in an intelligent fashion to address high-priority client issues. Delivering limited functionality outside the firewall early on may be viewed favorably from a marketing and competitive standpoint if expectations and risks are managed, positive word of mouth can be captured, and an early foothold in market share can be gained.
There may also be situations where a frequently-updated, partially functional beta approach might be viewed as inappropriate. For example, consider a comprehensive re-architecting of a complex financial, medical, or insurance system. The ability to employ a limited-functionality release mechanism could be seen as risky depending on the degree to which back-end or interfaced systems might be impacted during development, and depending on the actual access provided to a public beta. In such development efforts, a frequent-beta approach might be appropriate even if the overall availability of the beta software is restricted to a controlled development-and-test environment.
This could be an issue of "scope management" that any development manager will need to control, whether the product is a social software product appealing to pre-teens or a financial management product in a highly regulated business environment. Whatever the application, modern tools enable developers to communicate and obtain useful feedback in a fraction of the time than was possible in the past. With appropriate management practices and controls, many projects should be able to take advantage of early beta approaches, and we see the evidence of this all over the web
Now, if I could just get paid for helping developers test all that beta software that is flooding the market!
