Most of today's RTMs are barely beta quality.
Until recently, an OS brand wasn't good enough to use in production before the 2nd Service Pack was released.
Oh, hell ... some companies don't even perform any SQT before releasing a new version (what was the name of that robot sounding OS??).
Remedial Comics
I am not a programmer. I have, however, worked closely with them over the years in my role as a system administrator. In a properly constructed development environment, there is a fairly standard process for writing applications and putting them into production:
- Write and test code locally on development workstation/server.
- Submit code to version management system.
- Deploy code to staging environment.
- QA testing in staging environment.
- Return to step 1 to squash bugs detected in step 4.
- Deploy code to production server.
- Final QA testing. Any show-stopping bugs at this point send the process back to step 1.
Unfortunately the development process in a very small startup company may end up cutting corners because they cannot afford a separate staging environment or experienced QA testers that can find issues and debug the code. There may not even be a proper version control system in place to keep track of what went wrong and which build of the software the problem occurred.
It’s understandable that small startup firms can’t afford to pay for a good process that controls quality; all too often, however, these bad practices are carried forward even when they finally can afford it. It may eventually affect their business financially if they don’t manage to get control of their code and maintain standards. Some companies do learn; they hire the right people and build the right environment to facilitate good development practices. Others do not, and they spend the entirety of their existence getting bug reports from users and playing catch-up with system patches.
Larger software development companies–such as Microsoft, Oracle, Adobe–stick to established coding practices and launch their software when they feel it is stable enough to go to market. Of course, this isn’t always the case. Microsoft had an embarassing experience with the launch of Windows Vista; it was slow, bloated and buggy. It was an unpolished product and it showed. In comparison, their launch of Windows 7 was dramatically better, with a much more stable, mature product.
Many software publishers also provide early beta testing programs so that customers can try out the new software before it’s ready to ship in exchange for their participation in bug testing and reporting. This can be both good and bad–the technically savvy users usually know what went wrong and can help determine the cause of a bug. The technically unsavvy people, however, may be unable to provide any more information than “it locked up”. Anyone who has done help desk work knows what I’m talking about. And if you think I’m kidding, take a look at Not Always Right.
There is a darker side to this practice, however. All too often there have been customer complaints about companies that knowingly and deliberately release unfinished, inadequately tested software so they can get free beta testing from their customers. The most egregious offenders of this practice are MMO game publishers. I am not going to go into detail of which MMO publishers did this. I will, however, provide links to articles with examples of developer issues.
To be fair, one of the most frustrating aspects of publishing and running an MMO game world is supporting it. You need to have a distributed server farm, you need service people to administer customer help in-game, you need to police out the spammers and bots. Some publishing companies work in conjunction with a MMO management company like NCsoft or Turbine, providing the software while the management company handles the day-to-day aspect.
There’s also the aspect of deadlines and shopping seasons. If you’re publishing a software package that could make or break your company and you miss the Christmas shopping season, you could find yourself out of business by January. Many publishers take the risk of pushing out an unfinished product with promises that the rest will be delivered “real soon”.
The problem with these issues is that the customer is the one that ends up paying. Collectively, people are paying billions of dollars to be unpaid beta testers. They are paying for the “privilege” of being saddled with unfinished and sometimes unusable software because the developer either couldn’t afford to meet their deadline, or deliberately rushed to release in order to save money and make the user pay to be their tester.
Personally, unless it is stated up front that I am going to be compensated in some way for my efforts of providing free QA and testing to the software developer, there is no way I am going to pay for an unfinished, buggy application that wasn’t ready for market.
It doesn’t look like there are any real solutions to this dilemma. Software publishers have no financial incentive to improve their development/release practices if releasing software early saves them a boatload of cash. And there will always be people willing to pay through the nose for an early release of software even knowing that it might not be functional enough to use.
The real solution for customers, however, is to hit the developers where it hurts the most: in the wallet. Don’t buy those unfinished applications. Don’t pay to be someone else’s guinea pig. Unless a software publisher offers you discounts, free addons or services, there is no reason why you should give of your own time and effort.
A software developer that has an open beta test period where customers are given free access to use the software and services in exchange for testing is doing it the right way. You’ll get more evangelists for your product if you treat these early adopters with respect instead of looking at them as free labor.
Real Life, by Greg Dean
