CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In past years, it seems there has been an increased reliance on the public testing of beta products. Companies such as Microsoft have put a much greater effort into public betas, Community Technology Previews (CTPs), and other interim releases of products well before the “final” release actually happens. Not only does this often cause confusion for many in the marketplace who don’t recognize the difference between a prerelease and the real release, but it also can open a company to added risk that something might be overlooked.
What if something is overlooked? What happens if you forget something simply like checking to see what happens on a leap day or on the last day of a leap year?
If you did a public beta and if there is an issue, can you then blame the public for the failure? The public missed the issue, so can it be their fault?
This past week, Microsoft was hit with a bug that the public didn’t find in one of their products. Of course, it was a bug related to a specific date, so it is no surprise that it wasn’t found prior to it happening. It was a case where internal testers should have found the issue in standard testing for leap years.
In this case, Microsoft 30 GB Zunes have a bug relating to the extra day in a leap year. The bug causes the device to freeze on the Zune logo screen. Worse, you couldn’t turn off the Zune, nor did any of the buttons do anything. Because the bug restarted the Zune, most froze.
This issue was noted by many in the media and by hundreds if not thousands of people on the Microsoft Zune forums. As an owner of a 30 GB Zune, I can vouch for the error as well because I was hit with it too.
Microsoft seemed to be caught by surprise with this bug. I know this because for most of the day of the bug, the Microsoft Zune site simply stated that they were aware of the bug and were working on it. It was only later in the day that any “details” were released, indicating it was date related and would resolve once the calendar rolled to the new year and the Zune was reset. Of course, to reset, the Zune users were required to drain the battery and then wait for the new day.
Bugs in software happen. As developers, we know this. In truth, we have likely caused a few ourselves. A date check on a leap year, however, seems like a basic test case for any device or application that has uses dates in any context. If there wasn’t such a test case for the Zune devices, it seems like there is a Quality Assurance person at Microsoft destined for a very bad review this year, assuming that person still has a job.
What is more interesting is the fix that Microsoft provided for the bug. They simply had people wait it out and then reset their Zune. This is actually not a fix, but simply a workaround that should buy Microsoft four more years. It will be interesting to see if a real fix is made before the end of 2012, or if Microsoft gambles in the hopes that most of the older 30 GB Zunes will be replaced or gone by then. If Microsoft ignores the issue and the Zune still exists in 2012, there are a lot of consumers that would have every right to complain.
When my Zune froze, I searched to see if I could find out what happened. I found that others were having the same problem, and that a few people had offered solutions. The solutions being suggested fall into the ‘witch doctor’ category — such as the suggestion to open the Zune case and disconnect the battery. What is scary is that people seem to be following these unofficial suggestions! Not only does something such as opening the Zune case void the warranty, but it also risks greater damage to the device. The only thing worse than being hit with a buggy product, is being given bad advice on how to fix the bug!
Bugs happen, however, and companies are still accountable for testing. This is true whether they have public betas or not. If the “Z2k” issue was really just a result of it being the last day of the year on a leap year, Microsoft should have caught it.
From a developer’s perspective, just as we can’t rely solely on the public for testing, We should also also use caution on relying on the public for solutions. Sometimes, suggestions are made that are not the best answer. But then, as Microsoft stated, just wait until tomorrow and things might be better!
At least until December 31, 2012.
