On Dec 31st my Zune went into a coma. It wasn't pretty. It stayed in this perpetual start up screen. It didn't respond to any outward stimuli. And it turns out I wasn't the only one affected but every 30GB Zune player on the planet had the same problem. The geek press was a calling it the Zune Apocalypse.
My Zune is not Responding! Somebody call a doctor!
Fortunately it was a short lived Apocalypse. The Zune software had "a bug in the internal clock driver related to the way the device handles a leap year. " <Click here for a story about Microsoft's official response.> Which basically says, "Wait 'till New Years officially gets underway and everything will go back to normal. " Which it did by the way. My Zune is back and happily providing me podcasts, like Radio Lab, for me to enjoy during my work commute.
But here's the best part of the Microsoft press release:
"... there was a widespread issue affecting our 2006 model Zune 30GB devices (a large number of which are still actively being used)."
The parentheses indicate to me that Microsoft is actually surprised, yes surprised, by the fact that many people would actually use the device for more then two years. --- A device these people spent more then $100 to own. -- Did Microsoft really think that customers would get tired of these things after a few months and get rid of them? What kind of short sighted development is that? And how does any software engineering team working on a internal clock not include leap year into their calculations??
This bug could have been caught and eradicated if the software went through a peer review. In the SE class I teach I explain that the two biggest Quality Control Points are:
- Peer Reviews
- Unit Test
These should be protected at all cost.
But even a peer review can fail if you don't have the knowledgeable and experienced programmers on the team in order to help catch errors or discover overlooked industry conventions. So I also emphasize to my students the heuristic: variations among people account for the biggest differences in software productivity. So always try to hire good people.
