Go Straight to Content

What I'll Be Ranting About

Good development practices bring us quality code, confident systems, and missed launch windows. When do you refactor and when do you factor in the passing time? As engineers we need to design what is possible and capable. As programmers we need to turn imagination into reality without a physical product. As developers we need to bridge the gab between that engineered vision and the end product.

I also blog more personally over at my tumblr page.

I am available for small contracts, consultations, tutoring, and other development services. My "skills" as a technical writer are also available. If you've got anything you'd like to talk to me about or for me to see, drop me a line.

Thursday, January 01, 2009

How To Prove Code Review is Important

The infamous Zune 30GB failures were traced to a leapyear issue, and apparently they use some code we can see in the Freescale codebase. Take a look at the following sample of code, which determines the year from the day number (counting from January 1, 1980). I don't know about you, but the infinite loop is immediately obvious. On a leapyear, the main loop continues when days = 366 and the incrementing is never reached, because days > 366 fails.


Am I naive to think that even a casual code review would have caught this in a moment?

year = ORIGINYEAR; /* = 1980 */
while (days > 365) {
if (IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}


UPDATE: Fixed formatting issues. It looked fine when I posted it, honest!

Blog Archive