Oct 172016
 
 October 17, 2016  Posted by at 9:21 am Dev Ops, Not So Stupid Questions  Add comments

All software has one or several release cycles. Even if it’s not planned, there is always an underlying concept of a release cycle. A discussion around the when’s and where’s. Another discussion around the who’s and when’s.  And so on.

A pretty and linear release cycle might look like this (at least in the mind of the project manager or sales):

software lifecycle milestones

The above diagram isn’t a circle (to demonstrate a cycle) but I think you get the point. The startup I’m working for are in Beta stage. We got there a few weeks ago from Alpha. The major change for us was allowing customers that had signed up for the ‘experimental’ track (our SaaS is a two track system) to start using the product. At Beta stage (for us an open-by-invite beta stage) we feel confident in the accuracy of our calculations and data management, but there is a lot of testing left and we are still tweaking performance. The feedback from the customers has been extremely valuable, as they report issues and expectations we haven’t picked up on before. That requires a lot patience and understanding from the customers, and a vulnerability from our side as we are exposing the system at such an early stage. Our RC (release candidate) is planned for mid-November, and RTW (release to web) early next year. But we might not get there.

Because we might end up with a system that will for forever be in perpetual beta. I’ve got a feeling we are one of ‘those’. And it’s not a bad thing.

But what is a perpetual beta?

perpetual beta

Do you remember Google mail? Being in beta for years? That’s perpetual beta. It’s a stage during open beta that sort of also becomes GA (general availability) at the same time. And the system is there for a long time. A long, long time. Maybe ‘forever’. Why on earth would anybody do that? For as long as software has existed and available to the general public people have complained about the slowness of releases. Features not representing expectations. And all that comes with lack of communication and adding lots of time to get to the ‘tada! -its perfect! Let’s let it out’-stage. Perpetual beta takes care of that (not all of it of course) by releasing the software while it still has bugs and is undergoing feature updates. It is considered stable enough to stand on its own two legs, as well as being usable. The customers become co-developers as they take part in the development process by reporting issues and requests. There is no traditional ‘final’ release and subsequent ‘hello maintenance and support stage’.

The reason why I’m thinking that we might end up doing so is because we are exploring the domain and ways to extend and adapt the system together with our customers. Additionally, our setup on Azure allows us to easily maintain a perpetual pipe. We cannot predict and explore what would bring the most value without a proto. This while neither we or the customers want to pay and wait only to discover that its useless. Although we target enterprise companies at this stage the number of actual users is fairly scoped, predictable and we are able to have direct dialogues with them. We, as a company and team, are transparent and embrace the positives of sharing early – with faults and all.

I’ll let you know by next summer if we end up ‘Google-Mailing’ it.

What is your take? How does your company/you deal with releases?

  3 Responses to “(Not so) Stupid Question 294: Where in a release cycle does a perpetual beta belong?”

  1. Perpetual beta is a good way to offer a cutting edge, constantly evolving product (read: moving toward your customer goals at a rapid pace :P) without putting significant pressure on your team for downtime, documentation, backwards compatibility. — That being said, the gray area can be abused, where no or very poor documentation is provided, no backwards compatibility is offered, and a over reaching feeling of unreliability. All that being said, GMail is a perfect example of perpetual beta done right IMO.

    I’m curious if employee/stakeholder feel uneasiness when beta has no end in sight. Forever having a “beta” tag on your product might be a bit demoralizing?

  2. The company I work for uses some proprietary software that we develop for internal use. It has been in perpetual beta since I began working for them nearly seven years ago, and will always be beta in my opinion, as there are always new features being added, bugs to fix, improvements to make! It is definitely not a “bad” thing.

  3. I think a perpetual beta is a marketing “get out of jail card”

    Most software houses now should listen to feedback, improve, fix bugs, and improve as they go anyway. In reality there’s very little difference between beta and live (except perhaps how hard your sales guys are pushing).

    Reacting quickly should not stop when a product passes a mythical line from BETA to Prod

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)

What is 3 + 15 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)