What Does “Beta” Mean?

I’ve been a “beta tester” for years.  For quite a few well-known corporate behemoths, and some lesser-known small groups.  It’s fun.  It can be cumbersome work at times, but most of the time it’s just fun.  I get to play with cool new things that nobody (ok, well, a few other people) either know about or get to experience.

The “experience” has been evolving since I first got into this back in the late 1990’s.  Back then, the term “beta” applied to private testing of products or services whereby the vendor sought an interactive dialogue with their testing community.  Quite often on a one-on-one basis.  Those days are, for most larger corporate programs: long gone.  In that realm, a “beta” program denotes an open-public “community preview” where the community is treated anonymously and their feedback is filtered such that only problems with existing features are considered.  Requests for new or enhanced features are ignored. Period.

This is where the old “alpha” term comes back in.  It was barely used in the old days.  Heard of, yes, but barely used.  Today, for larger vendors, the “alpha” programs are the crown jewel of private interaction and feedback communication.  Those programs exist, but they’ve been hijacked by the marketing suits, so that now they only “invite” (internal term is “target”) or accept specific demographics.  By that I mean clients that present the biggest potential revenue from winning them over.  So now you need to fall into one of the following groups to be considered valuable for alpha trials:

• Members of large corporate clients in markets channels where the company wants to make an example “win”
• Members of the Press or book/journal authors
• Partners who develop critical (e.g. “synergistic”) products and/or services

An “alpha” trial is where the product or service is still taking shape.  There is room for adding and cutting features.  It’s the lump of clay dropped on the throwing wheel as it just begins to turn.

A “beta” trial is where the product or service is fully shaped as intended, and the potter simply wants to know if the finished product works or has leaks.  They don’t want to hear about changes to the shape (unless it presents a “critical stop” in the workflow to getting it released).

Another aspect of the retail (“commercial”) software product development process that has changed dramatically, but slowly, is the rationale process for setting goals for upgrades and enhancements.  In the old days it was just a push to make the product more “cool” and “robust”, maybe to match and overcome a competitor.  Today it’s about ROI.  The suits decide what goes on the hit list and what gets cut.  Not the developers.  The developers are becoming more and more of a commodity.  The machine that turns the goals into something tangible for sale. The architects are the only valuable rarity (which is why the “fellow” and “evangelist” positions are prized).  Designing the solution is one thing.  Building is another.  In the old days it was the building part that took center stage.  Today it’s about the business case, the service model, the probability studies for revenue and profit.  Risk mitigation, and so on.  They are the ship’s captain.  The architects are the chief engineer. The developers are in the engine room, shoveling coal into the furnace.  They won’t say it, but most of the suits inately feel this way today.

(caption: don’t they look happy?)

As a technical minded person, you say “but this little feature change would make it so much more useful and easier to do my job”.  But the response is now: “but what does that get US?”

The software technology world got a lot more complicated over the last 20 years.  Business crept in.  Marketing slid under the door.  Legal kicked the door down and took all the remaining chairs at the table. The techies are now serving drinks.

So, while some old-timers still wade into a “beta” program with decade-old expectations of submitting “wishlist” requests and asking for small adjustments, they soon are hit with the frustrating wall of silence and form responses.  This is more true for the lone developer or consultant than for the folks who fall into the demographic list above.  We just have to readjust our expectations and understand the bigger picture, so we can avoid getting our feelings hurt.