Be consistently wrong

If you’ve been maintaining code and legacy software as long as I did, you would have your fair share of horror stories. Some obscure program error would happen, and you would spend insane amounts of time tracing an elusive line or lines of code to find the pertinent root cause. Then you’d correct the offending code and send the new-and-improved program back on its course.

Sometimes, after you’ve tracked that bug, you were only able to correct the error. I believe it’s called data patching. Basically, the program completed, and there’s only this teensy weensy little piece of data that’s just a tad out of place.

You scoured the original data for telltale signs. You pored over reams of printed code. You debugged, you inserted printfs to look at output and you even tried flailing your hands wildly in the air, asking skyward “Why me?”. All to no avail.

Since time’s a-wastin’, and you’re short-handed, you did the only thing humanly possible. You changed that piece of data so it became correct. Then you ran the other programs that were held up by this unfortunate incident.

The next time this particular error came up, you knew what to do. Since time’s still a-wastin’, and you’re still short-handed, … well, you know what happened.

And it always came up. Consistently.

Actually, my point isn’t to encourage you to let bugs triumph like this. My point is that, when you make a decision like this, you have weighed the consequences and consciously, rationally and logically decided that the bug can stay. Fixing the bug costs more than fixing the error in the short term. And you’re willing to take the responsibility of long term costs.

Basically, you’ve decided to be consistently wrong. The keyword is “consistent”. Don’t go fix that bug, find that there are other bugs, and then you’re too lazy to go fix those bugs.

If you want to fix it, really fix it. Don’t give it a halfhearted attempt. Make up your mind. Give it your all. Either be consistently correct, or be consistently wrong.