If It Ain't Broke, Don't Fix It

One of the projects that I sometimes still get dragged back into now and then is about a week and a half from going to production. This is a fun time when the last of the defects are quickly being fixed, and testers scramble around to run the last of their scripts. Then you see a defect that is in code that you know has been working for a long time. After investigating the defect for a bit, you run into the buggy line of code.

That's when I usually say out loud, "How did that get in there?"

The very first thing I do in this case is search through the file history in Source Safe. Sure enough, something was just checked in prior to today's build. So I look at the check-in details. "Fixed Defect #xxxxx and changed a couple other things".

"Great. I wonder what 'other things' got changed."

I've run into this problem at the end of more releases than I care to remember. There is usually at least one developer in any group who loves to tinker. They usually say to themselves, "Well as long as I'm working in this file anyway, I might as well clean a few others things up too." And that's when the new defects come in.

While it can be all well and good to change around some ugly code during development, you should always let ugly code lie at the end of a release. There simply isn't enough time to test your changes. And your changes should be tested. What's worse, is that these "minor changes" are rarely ever called to anyone's attention when checked in. They're simply snuck in, so people don't know that they need to test them. As the old saying goes, "If it ain't broke, don't fix it."