When I worked in Microsoft on MSE antivirus, we had several stages of pre-release: Alpha, Beta, RC. The biggest difference between these stages were bug fixes. Each time we fixed more bugs, and usually updated some minor features.

Apple works in the same way. Look here: http://www.techrepublic.com/article/pro-tip-how-to-create-a-bootable-usb-installer-for-os-x-yosemite/

They released a beta of Yosemite OS, but the beta is full of bugs.

Why do these big companies work like this? Isn't it better to release a beta version that was tested very thoroughly but one that just doesn't provide all the features that the final version will provide?

  • 2
    Don't you wonder why they release apps with bugs?
    – JeffO
    Jun 8, 2014 at 16:14
  • 2
    related: "Why software has so many bugs?" & "Who writes bugs in software?"
    – user88637
    Jun 8, 2014 at 16:36
  • I like these comments, very true and still funny :) Jun 8, 2014 at 18:57

4 Answers 4


Why do big companies work this way?

Because by the nature of their size, they also have big install bases. Part of the purpose of releasing a Beta product is to test on real-world combinations of hardware/software that the company could not do internally. There are simply too many combinations to simulate everything in-house. So after Alpha, some of the mid-cycle testing is outsourced to the end-user.

Release Candidates are when everything all comes together, thorough testing and reasonably complete feature set. You are putting too much expectation on Beta products. Beta is still very much representative of a product in active development, full of bugs, missing features, etc.


bugs are found and not pre-known

Having one phase doesn't help much with enhancing the code base, you can't figure out all the bugs in one phase.

Having multiple phases let the organization reorder its priorities, gets feedback from the users and enhance the code accordingly. Priorities change with testing, developer discussions, and code base mature with each phase, if you only want one phase this means that you have to deliver without any feedback, you might be focusing in one area before finding out that you were doing it totally wrong, and because bugs are found, some parts of the application might be more buggy than others, again it helps you figure it out.

From a project management point of view, this helps set milestones for the project and managing the project resources..

  • Of course you need milestones. But each milestone you should deliver new features in order to assess how useful they are, rather than fixing bugs. I don't think you should use the beta community to find bug. Isn't it better to use the Beta community to provide feedback on 100% working and tested features?
    – Eugene
    Jun 8, 2014 at 10:12
  • 1
    @Eugene: wouldn't it be a waste of time to develop a feature, ensure it is 100% bug-free, put it up for beta only to learn that nobody really cares about the feature? Jun 8, 2014 at 10:24
  • That's also true.
    – Eugene
    Jun 8, 2014 at 10:25
  • 3
    It's also unlikely that you're going to use the product in the same way as your customers, especially if your product is used at scale. So you may not even be capable of discovering all of the relevant bugs on your own. Jun 8, 2014 at 16:28

If you wait until all possible bugs are found, you'll wait forever. Voltaire wrote it first:

Le mieux est l'ennemi du bien.

(translated: “The best is the enemy of the good.”)

It means that seeking to create perfection means you'll never actually produce anything good at all; you'll continually be not finished because you're not quite perfect. You must stop and release. Since you know you're not actually attempting to produce perfection (merely good enough will do; balance the cost of not fixing a bug against the cost of not releasing because of the additional delay) why fret that things aren't perfect?

What tends to happen is that people produce alpha versions of software while they're working on the major features; these may well be internal only, or only released to a very select group of external people, and will probably be rather broken in other ways. Then, once the major things are in place and roughly working together, a beta is created and sent to a larger group of people. This is where QA really gets their teeth in, ferreting out all sorts of minor bugs, and where the people who are very keen on getting the new features — enough to tolerate the fact that the software is known to be buggy — can get early access. There may even be a few beta cycles, as bugs are ironed out (including eventually all the show-stoppers, hopefully).

Once the cost of fixing bugs is exceeding the cost of leaving them unfixed, it's time for the full release. If you don't like bugs, that's what you should wait for. (The really conservative will even wait for the first few official patches to come out, so that even really obscure stuff gets squelched.) But some people simply are much keener on getting at those features: they're the ones that betas are aimed at (and alphas are usually for people who are pretty close to the development process only, as they're usually missing key functionality).

Agile processes try to shorten things by keeping the amount of time that things are broken really limited and putting the customer close to the development, but it's not suited to all software. Anything aimed at having a really wide release (e.g., commercial products) simply cannot have all the customers there; that forces the sort of release strategy outlined above.


There are a few things to consider:

  • Not all bugs are going to be found until "something" gets released, so why wait until you smash the very last bug when you know they'll be more anyway.
  • Some bugs may not affect as many users or in many use cases.
  • Bugs can be found/created at a rate much faster than can be debugged.
  • Some power users (like programmers) like to see the software in action sooner rather than later regardless of the bugs.

They release apps with known bugs, so why would Beta versions be any better?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.