Explaining the Excel Bug

Floating-point to decimal conversion is a little bit trickier than usually thought (cf. Steele&White, "How to Print Floating-Point Numbers Accurately", SIGPLAN '90, pp.112-126, 1990. and also Burger&Dybvig, "Printing Floating-Point Numbers Quickly and Accurately", PLDI '96, pp.108--116, 1996.), and tweaking the algorithm can easily introduce special cases in the code path.

Now I don't have any idea why Excel had such special cases around 65535, but this incident seems to confirm my growing suspicion that it is wrong not to test 100% of code paths. Some of you may say off course it is, but I've seen programmers that just test a few sample points and then bombarding the code with random input and say it's working. I myself have been bitten by some bugs hidden in rare code paths since I was lazy to construct a special input that tests the path, which sometimes takes some effort. (I haven't used automated test case generation tools; any opinions?)

Joel is letting them off easy when he talks about how it's unlikely that this bug would come out in testing. He's right that black-box tests wouldn't catch it. But, obviously someone wrote some special-case logic for formatting 65535 and 65536, and there's absolutely no reason that that special case logic should be there. That code should have been flagged during code review and terminated with extreme prejudice.