But when Leopard was released, we kept getting tech support calls exclaiming that any machines that had been partitioned using our software were failing to install the new OS successfully. Days went by and our QA couldn't reproduce it; then someone from Apple calls directly. Turns out it was our code: the gap partition we created was inexplicably one block too small. Since hardware block size is 512 bytes, and the gap partition is 128 megabytes, this accounted for a discrepancy of but 0.00038% of the total bytes in that gap partition.
An effort was launched to track down the problem, and after pouring through code that no man should have ever put to disk in the first place, the offender was found.
As it all too often turns out, the problem was minor miscalculation in a small part of a larger calculation to determine the starting and ending addresses for the new gap partition. Considering that these "gap" partitions are just that, blank gaps left there to ease future software development, we were apparently getting by with the fact that no system app or installer actually checked to ensure these gaps were of the "required" size.
That is, of course, until the Leopard installer. In which Apple decided, for the first time, to check and enforce the size of these partitions, causing the installer failures we've been hearing about constantly lately. All because our code calculated 262,143 when it really meant 262,144.
If you've ever skimped on testing a bit of code where you thought an off-by-one bug might be lurking but weren't sure, hopefully now you see how much harm even 0.0004% can cause. (Especially when you're writing dangerous code to muck with partition tables directly!) Just imagine what would could have gone wrong if the offending code had been in a more sensitive or destructive algorithm than it was...