Apparently, the code that caused the Microsoft Zune 30 GB units to malfunction on New Year’s Eve was part of the driver code written by Freescale, the makers of the MC13783 processor used in the Zune.
Shame on you, Freescale, for writing buggy code.
And shame on you, Microsoft, for trusting Freescale and not checking their code before putting it into a product with your name on it.
Entries (RSS)
Are you saying you exhaustively test every library that you use in a given programming language? This looks like a bug that Freescale should have caught with normal boundary tests during unit testing.
How does it work on day 1 of a normal year?
How does it work on day 1 of a leap year?
How does it work on the last day of a normal year?
how does it work on a normal day of a leap year.
If they take into account the extra second added this year, then that would be another test.
One of the primary reasons for using a library is that it is, in theory, tested and known to work. I don’t typically unit test a third party library. I read the API, I make sure I understand how to use it and then I use it. I unit test my own code.
[…] Apparently, the code that caused the Microsoft Zune 30 GB units to malfunction on New Year’s Eve was part of the driver code written by Freescale, the makers of the MC13783 processor used in the Zune . Shame on you, Freescale, …[Continue Reading] […]
Well, the post is actually the greatest on this worthy topic. I fit in with your conclusions and will thirstily look forward to your incoming updates. Saying thanks will not just be enough, for the phenomenal lucidity in your writing. I will directly grab your rss feed to stay abreast of any updates. Delightful work and much success in yourbusiness efforts!
William, I moderate all the comments I receive on this blog, and I discard almost all of them, as they’re mostly spam. I know your web site has little to do with my post, but you’ve expressed your flattery so well, I’ve decided to approve your comment for posting. Merry Xmas!