Risky Business
You've either experienced this first hand or heard about someone that has. You have a group project due next week and things are going great. By the assignment due date you have everything but a few small bugs worked out. You're looking at a 95%. But one team member just can't let those last little bugs go. The night before he stays up and tweaks the code (or if he's more desperate rearchitects vast portions). The bugs look fixed and he doesn't tell anybody that way it's a "surprise" when you get a 100% instead of a 95%.
You get the project back and low and behold you have a 62%. There's a collective *GASP*. How could this have happened!? Thanks to your teammate's last minute changes, the bugs were fixed but a core scenario ended up being broken.
Was it wrong for him to try and increase the quality of the project by fixing the minor bugs? The answer is to think of the change in terms of risk. As you get closer and closer to shipping a product, the risk for making a change goes up and up. Even a small tweak can cause a program to misbehave and in ways you never anticipated. This is why software needs testing: to try and find new ways of using the product that the developer didn't think of. So while your change is only one line and looks innocuous enough, you could have just broken your application's ability to save.
In class work, the risk comes down to is a 100% better enough than a 95% to risk getting a 62%? If not, don't risk changing the code because it's just not worth the risk.
It's the same in business: does the issue impact the customer enough that we need to risk making a change to accommodate for it? There is no simple answer here, but the day before shipping this question will get an enormous amount of weight. If there's an issue that needs fixing and you change the code wrong, you could end up shipping a product that's dead on arrival. This means recall and loss of profits (a possible company dooming experience if bad enough). Worse is that you only have a short amount of time to test it. Most bugs can take months to be found, others won't be found until the customer starts using the product extensively. You have to know that whatever change you make could very well throw all the work you've done over the last years away.
Risk will be defined differently across companies so there's no straightforward advice to give on how to evaluate the risk of a change. One piece of advice I can give is to listen to senior developers who have been with the company longer than you. They've seen more and will have a larger picture of the product as a whole than you do as a new dev. Be prepared to have someone reject a code change you make, even though it's just a trivial, easy code change and you really want to get it fixed and you don't understand how in the world the original dev didn't do it this way the first time. Whenever I find myself going down this road it's a clear sign that I don't understand why the code was written the way it was. It may have taken months of testing and weeks of investigation to find this obscure but troublesome bug that made the code the way it is and changing it back will put the bug back in again. Here's a good time to look at source history and see who wrote the original piece of code and why, then you'll have a larger understanding of the code and be better prepared to make an informed decision about the risk of changing it.
There's a great post on Chris Pratley's blog about how relinking Office 97 exposed an obscure bug in the Pentium chip which caused the application to crash, a good example of how no change is truly safe. You can read it here.
