Archive for April, 2010

Perpetual beta

April 25, 2010

Software development processes are experiencing a shift from occasionally releasing new versions with huge changes and lots of new features to frequently adding small changes to their products. Applications being developed in this way are described as being in a ‘perpetual beta’ stage. Nathan Wallace presents the diagram below as illustrating the perpetual beta development approach and says about it “Adopting this cycle brings certainty and momentum to end users while ensuring continuous improvement and low risk release management for developers. Developers move seamlessly from one version to the next, with only a small cross-over for bug fixing during the Beta period.” (Wallace, 2007)

Release cycle diagram

An example of perpetual beta software is the suite of programs by CloudBerry Lab. These programs demonstrate some of the characteristics and best practices of the perpetual beta approach. CloudBerry was founded in 2008 but has several versions out already. This shows frequent releases and therefore some adherence to the best practice of ‘release early and release often’ (in examining the site, I didn’t find evidence of what stage (how developed/bug-free) the new features were at when they were released, so I can’t tell how ‘early’ these releases were).

Another characteristic of ‘perpetual beta’ software is the continual addition of features in place of ‘version’ releases and again, CloudBerry partially conforms to this. Whilst it does release in ‘versions’, the number of changes introduced with a new version is relatively low, meaning the ‘versions’ could perhaps be classified as small, continual updates and not substantially different ‘editions’. One of the benefits of changing things slowly is that it gives users a chance to adjust to the new features instead of throwing them into a completely unknown environment.

CloudBerry also mentions ‘coming soon’ features, indicating that the software is not currently complete and remains in a beta stage. This could be helpful in a few ways – firstly by creating anticipation and a sense of activity/progress that catches and holds the users’ attention and secondly by helping to lessen the shock and bafflement of the announced changes when they arrive.

Beta testers are important because it is almost impossible for developers to test their software in all of the various conditions that might occur” (Digital River, 2009) Beta testing is an enormously important part of any software production and, interestingly, CloudBerry seems to implement it differently at different stages of software development. In the earlier stages of development, CloudBerry invites people to sign up as beta testers. This is conformance to the best practice of ‘engaging users as co-developers and real-time testers’ and ‘split testing’ (where only a portion of site visitors are shown ‘coming’ or ‘in development’ features and asked to provide relevant feedback). After that, however, the option to become a beta tester is removed (presumably when the software is first formally released).

Once the software has been officially launched, CloudBerry lets it fall into the ‘version release’ pattern (as addressed above) with new features continuing to be added in small clusters. At that stage, a link is still provided that takes visitors to a place where comments can be left and read (meaning users can continue to give feedback).

Provide testers with incentives to communicate and provide feedback. Beta testers that provide comprehensive feedback will often welcome, and expect, a complimentary release copy.” (Digital River, 2009) On the page where visitors can sign up to be beta testers, CloudBerry makes it clear that they will “grant a limited number of free licenses to the most active beta testers who will provide the most valuable feedback”.

Beta testing isn’t always only beneficial to the software developers. Thomas Nau stated that “doing betas and implementing new OS releases early helped a lot in system administration and overall utilization of the machines due to new tools and features. He described his positive experience in one sentence: “Betas ensure that you stay on the leading edge of technology.” (Nau in ‘Get the best benefits from using beta software’, 2008) By making users aware of the benefits to themselves, software developers may be able to attract more beta testers and so improve the feedback they receive about the beta software.

Overall, though CloudBerry doesn’t implement all of the best practices related to perpetual beta software, it does include quite a few of them and relatively successfully so.

Advertisements

Software above the level of a single device

April 18, 2010

Useful software written above the level of the single device will command high margins for a long time to come.” (David Stutz, 2003).

Although the quote above appeared in 2003, the principle it articulates remains true today. It recognises that the computing world is experiencing a shift from desktop-bound client software to net-based applications that are accessible on a range of devices from the desktop to the mobile phone as well as a host of other devices. An example of this is an application called PocketSmith – an online budgeting calendar – as it exhibits some of the best practice principles put into action.

The World Wide Web Consortium states that “For some web content or application to be device independent, it should be possible for a user to obtain a functional user experience associated with its web page identifier via any access mechanism” (W3C, 2003) and PocketSmith implements this by maintaining its users’ accounts and data in such a way that they are accessible from both desktop and mobile devices. By not binding the users to a particular device, PocketSmith expands what it has to offer and appeals to a range of user types. Not all users would have a mobile device or a desktop and therefore would not be able to make use of all those access options but for those who do, the functionality is there and waiting.

If you ask me what computer I use, it’s the closest one. If you ask me where my data is stored, its in the web.” (Digital Equipment Corporation, 1997) This quote is apparently another old one, but it neatly captures the ideal of location independence. What’s more, with mobile devices being so advanced these days, the closest computer is often right in your pocket, so by offering mobile access, PocketSmith has made itself location-independent. As long as users have a compatible mobile device, they can access their data from anywhere their devices receive network coverage. Indeed, PocketSmith in particular makes use of the immediacy of mobile internet use – users can check their budget from any place at any time (for example while out shopping, a user could check to see if their potential purchase would fit within their budget). In this way, PocketSmith cleverly leverages the pervasiveness of mobile computing and internet – people seem to always have their internet-enabled devices with them and are therefore constantly online.

Another best practice that PocketSmith adopts is modifying the experience to suit the device – instead of presenting the same graphics on a mobile phone that a user would see on their desktop, the iPhone version of the application is much cleaner and simpler and only the core content is displayed.

Other best practices (such as harnessing the collective intelligence) haven’t been implemented because they involve online communities and the PocketSmith application deals with its users individually. In fact, trying to create community around its users would likely backfire since the application is centred around users’ financial data, which users almost certainly don’t want publicly available. Perhaps there would be room to use that data in aggregate, non-identifying form (say, to show the community the budgeting areas that large groups of people are struggling or succeeding with or room for a forum where users can trade advice and encouragement) but currently, the application is for individual or family use.