Almost invariably at the end of a software project, someone will insist on fixing an annoying but non-critical bug. Perhaps the browser will freeze if you hit refresh 200 times in a row, or maybe button text overlaps when you get more than 20 incoming calls during an outgoing call. The cry will go out, “We should fix this bug! It’s a simple change! It couldn’t possibly break anything!” Sometimes this will come from marketing; other times the engineer for that component will want to make the change.

Looking at the proposed fix, the change will appear to be fool-proof. Perhaps a variable didn’t get initialized properly, or a resource had a typo, or someone forgot a break in a switch statement. You may say to yourself, “There’s no way something this simple could possibly break anything, so let’s do it!”

Before you agree to a claimed “zero-risk” change, read this true story from Raymond Chen at Microsoft. It demonstrates how every change has risk, sometimes in unusual and unexpected ways. During the middle of a project, there’s time to find and react to any unexpected side-effects from a change; at the end of a project, the side-effects may be serious enough that dealing with them will delay the software’s release. Do you want to be the one explaining to the CEO that the product can’t ship on time because a “zero-risk” cosmetic fix introduced a serious problem into the planned final build?

So avoid the temptation, and at the end of a project only fix bugs that actually prevent the product from shipping.