Alpha, Beta, and Sometimes Gamma

I’ve recently come to believe that there is really no use to label versions as alpha-beta-whatever. There is no such thing as a final gold version as you’ll always run into bugs that need to be fixed. That final version needs to be patched with another final version and then that one needs to be patched as well. More often than not, developers seem to forget that software needs to be maintained.

The only reason people want to call something a beta nowadays is to let the users know that they can touch the software but not blame the developers if it blows up… since y’know… it’s in beta. If I had to decide, all software should be in perpetual beta.

How anyone wants to do their releases is up to the developers with their client to decide how the latter wants their software. The continuous integration crowd wants to do as many releases as they can so that the client can see the benefit of the product and give feedback.

@T.E.D:

If you ever read carefully the Java license, it explicitly says that you SHOULD NOT use Java to do stuff like: health systems, airport/airplane controlling devices, software to control/monitor military or nuclear devices, etc. Even though Sun promotes Java as a safe language, they’re very humble in admitting their software is far from perfect. And they don’t want people using it in these environments for they don’t want themselves to be open for suits (negligence suit for not fixing a bug quickly, anyone?)

Besides, SECURITY IS NOT A PRODUCT, IT’S A PROCESS.

You ought to read that sentence a thousand times until you grok it. Read Bruce Schneier’s blog for a more expanded explanation if you will.

You can have well developed code, reasonably bug-free, written in plain ANSI-C (not even C++). It’s just that you’ve got to be careful and methodic in your process - that’s what the whole CMMI is about. The Linux kernel is very bug-free now, and it’s almost pure ANSI-C (plus GNU extensions, plus some assembly sparkled here and there). And I’ve seen enough buggy code in Java and C# to understand languages aren’t a panacea.

@ Matt:
The German ss letter, properly called eszet, evolved from medieval scribes’ ligatures combining initial/medial s lower case letter and z letter. Have a look at:
http://en.wikipedia.org/wiki/Eszet

@Matt S: On a side note, why does the beta symbol look like the German ss symbol ()?

Better question: Why does the German ss symbol () look like the Greek beta? (Since Greek existed long before German.)

One thing to remember about the term beta software is that in the early days of computers, most applications had a single purpose, and had no user interface to speak of. Hence there were really no minor bugs – it either worked or it didn’t. So, if you turned something over to a beta test site for testing, it was because you thought it was done.

Beta Software == Release Candidate == unless someone complains, these are the bits we are shipping

Forget greek, let’s use honest labels like:

Vapor,
Crap,
You Try It and his buddy Try It Again,
and my favorite We’re Done.

Reminds me of Brave New World

Alpha children wear grey. They work much harder than we do, because they’re so frightfully clever. I’m awfully glad I’m a Beta, because I don’t work so hard. And then we are much better than the Gammas and Deltas. Gammas are stupid. They all wear green, and Delta children wear khaki. Oh no, I don’t want to play with Delta children. And Epsilons are still worse. They’re too stupid to be able to read or write. Besides they wear black, which is such a beastly colour. I’m so glad I’m a Beta.

I’m pretty certain that the perpetual Beta label has cropped up as a CYA (cover your tush) designation. That way, if there are horrific, show stopping problems you can claim still in Beta! Use at your own risk. Meanwhile, here’s our development cycle:

Alpha:
Features are ready for testing. We send out copies to very select customers because we’d like to get feedback on the general approach that we’re taking. Do we need to redesign or are we on the right track. Things may blow up horribly.

Beta:
Things are pretty stable and we’re looking for feedback on tweaks and bugs. We send out a more generalized release to a larger number of customers in various parts of the world. We typically include a questionnaire that covers all the major new features and asks users to test out their old methods for backwards compatibility testing.

Release Candidate:
Ready to go barring show stoppers. By the time we get to RC-5, this is usually when we discover massive flaws in the fundamental algorithms, huge gaping memory leaks, and thread and cross process synchronization issues. We sweat bullets for a few days and thank our lucky stars that we haven’t shipped yet!

Release:
Hallelujah! Out the door with you. Time for a cold beer and some pizza.

Approximately 3 days later:
First patch…

Actually, I’m being facetious. We have only had to patch one release over the past 3 major releases. I credit the fact that we have the best QC that I’ve ever worked with.

Nothing beats a high quality a href=http://tinyurl.com/58fcb7 Zeta/a release.

I read an article over at Yegges drunken blog rants that touches on a couple of points you mention. You mention the phases of a typical software development lifecycle. He believes, and I’m inclined to agree (despite my very limited knowledge) that web-apps fall under a different category. Namely, ‘servware’.

Hosting an application means that incremental updates can occur at any time. Bugs can be fixed instantaneously. Testing never stops! The users discover bugs and (hopefully) submit them, and a good application will have them fixed in very short order.

Given this ‘new approach’ to development, and based on the terminology used… is a web-app ever out of ‘beta’? Is it ever final?

I wonder how the pre-alpha/ alpha/ beta/ RC/ gold release process can be suitably used in agile software development. What are your thoughts on this?

Inder P Singh

Although I like using the terms (they sound cool!), we really could
all save ourselves a bunch of trouble by just using simplified terms:

Internal Release
Preview Release
Final Release

I’d rename that last one to Public Release because as it’s abundantly clear nobody likes to claim anything as finished these days. There’s always some change in technology to go after. What people should do more of is track features and changes and group them into different releases and have those 3 stages for each release.

Maybe I just like version numbers a bit more then google or whoever. They do have versions of gmail above Old html and new, they just don’t share that, which is fine by me.

There’s no such thing as Gold in software. As you mentioned, there are probably still numerous bugs left to be dealt with in the next release or service pack. Of course, there are numerous other features that have not been built. In fact, in my opinion, if there’s such a thing as Gold in a software, that software is already obsolete by the time it goes Gold

What’s wrong with Done and Not done?

Personally, I typically use preview or demo and then it jumps to just finished - even the end users know that preview/demo means it’s not finished.

If you ever read carefully the Java license, it explicitly says
that you SHOULD NOT use Java to do stuff like: health systems

Yup. I suggest that, for the purposes of this discussion, we take that just as seriously as Bell Lab’s (the creator of C)'s assertions to the DoD back in the 80’s that C is also not appropriate for such work. How seriously that is, I leave up to you. :slight_smile:

(Reference Source: ACM SIGPLAN Notices, Volume 28, Number 3, March 1993, page 314)

Besides, SECURITY IS NOT A PRODUCT, IT’S A PROCESS.

Actually, I agree entirely with this statement. However, that still doesn’t mean that its smart to go into the fight with one hand tied behind your back. In fact, it expressly means that you don’t do that. If you find someone doing so, how great is the rest of their development process liable to be?

Plain old C has been proven to (yes, proven) to induce more bugs than comparable code written in other languages. In some realms it is just fine to cut corners and use it anyway. After all, you can’t beat its industry support. However, anyone using it for safety-critical software when there is a better choice available should be ashamed of themselves.

Forget greek, let’s use honest labels like:
Vapor,
Crap,

Heh. I like that.

There are two kinds of software…

Forget greek, let’s use honest labels like:
Vapor,
Crap,

Heh. I like that.

There are two kinds of software…

What does CTP stand for? It’s not like CTP can mean only one thing, wikipedia lists over 20 possible meanings:
http://en.wikipedia.org/wiki/CTP
I hate it when somebody uses a TLA* blindly assuming that everyone will understand what you mean. Very often there’s several different meanings of the same three letters that could fit the same contexts.

I guess that in this case CTP most probably is Community Technology Preview but it might allso be Concept To Prototype (that might refer to a very early stage or something).

My point is: If you use an abbrevation/acronym less known than WWW, URL etc., at least check wikipedia if these letters leads to a disambiguation page or not.

  • In this case three letter abbrevation/acronym, just to show how annoying it is.

I had always assumed they just stood for ‘a’ and ‘b’ releases and the phonetic alphabet was used. So, in that sense, I have used ‘Charlie’ as a release moniker.

Anyone else ever had a ‘Charlie’, ‘Delta’, ‘Echo’ or ‘Foxtrot’ release?

I demand perfection. What am I supposed to do with love that is not perfect? Like the features don’t work nicely but hey, they love me?!