When Is A Beta Not a Beta?
Reading the news this morning, I ran across the following statement:
It’s very early in development but there’s a beta available if you’d like to try it.
Based on my background of hard-core product development, this seems a little bit contradictory to me. I always understood a Beta to be a feature complete product that’s only lacking a little polish and a lot of testing.
From the Wikipedia page on Development Stages:
Each major version of a product usually goes through a stage when new features are added (alpha stage), then a stage when it is actively debugged (beta stage), and finally a stage when all important bugs have been removed (stable stage).
This completely agrees with my understanding of development stages. So by this definition, the previous “news” statement should read:
It’s very early in development but there’s a pre-alpha available if you’d like to try it.
Granted, in the days when Google leaves a product in Beta for 2.5 million years, the whole notion of what’s a Beta can get a little confusing. But I don’t think anyone really disputes that a Beta should be feature complete. You may find a few must have features during the beta-test cycle, in which case you might have a second Beta cycle or you might postpone those features for a point release (depending on your cash-flow really).
But the attitude for a Beta should be: “If no one finds any bugs, we ship it.”
Comments
But the attitude for a Beta should be: “If no one finds any bugs, we ship it.”
Agreed. But I’m confident a full 0.3% of software companies actually do that.
Actually, Eric Sink has a great article on shipping a product with bugs.
Based on that article, I’d have to ammend my statement to read:
Eric’s point is that sometimes the cost of fixing a bug is just too great. Either you’ll miss the window of opportunity for your product or you run the risk of introducing additional bugs. It’s a good point, one that I often overlook — especially when I’m complaining about crappy software.