When something goes wrong with a program, there are many factors involved. If you are a developer at a company, chances are you are the last line of defense and the software issue unfolds in a manner similar to the following:
- User encounters the unexpected behavior in the software
- User fidgets around with settings and restarting things-if you're lucky
- Tech support goes over the basic stuff - "Is your computer plugged in?"
- The unresolved problem shows up on your desk.
The user's problem has now become your problem. When this happens I have seen many a developer immediately turn on their left brains and approach it in the following manner:
Is this really a problem that requires a programming fix?
Because lets face it, if the answer is "No", you're off the hook. You should still do all you can to see the problem is resolved, but you are no longer the solely responsible for the resolution. This gives a developer incentive to try to make the problem appear as though it doesn't require a programming fix. Some developers go to great lengths to convince others that there is nothing they can do to fix the problem. In the office it is quite common to hear your fellow defensive programmer say such things as "It works on my machine!" And since this is true, it must be something wrong with the user's machine, right?
How often will this issue come up?
Once the developer has conceded that there is something wrong with the code, they may still try to fight the fix. "Ok, sure it deletes the balance from their savings account... but how often will that really be a problem?" Although it is important to focus on the 80%, the one customer who experiences your bug and complains about it will be taking up 80% of your time. What is worse, is the user who scraps your program after experiencing the bug and doesn't tell you about it.
I'll just fix the symptom aka "The easy route"
The program keeps throwing the ubiquitous "Object reference not set to an instance of an object" exception whenever the user tries to save their work. "Hmm, well their work saves ok, so... I'll just supress that error message." When I see this being done in code, or I hear someone heading down that route, I die a little bit inside. For you see, that way madness lies. I once fixed an particularly nefarious bug wherein the actual source of the issue was being thrown and caught by an exception handler and subsequently ignored. If you do this, and someone else has to inherit your code (which is inevitable of a successful project), you will be sending that developer on a fool's errand.
Fixing the symptom is very enticing to novice programmers because it does a few things:
- It gets people off of their back
- Since it is quicker than fixing the real problem, it makes it seem as though it was a small oversight on their part. No biggie!
- It provides faster gratification. They get to play hero sooner.
- The easy fix is in line with their short sightedness - they do not expect to be working on the same code 2+ years from now.
Lastly, many novice programmers tend to equate any fixes with being the correct fixes. After all, a fix is a fix right? I would submit that the correct fix is almost always the more difficult fix. There are cases where the correct solution is a very small and elegant, and in those cases count your blessings. Just ask yourself this next time you are about to implement a bug fix: "In a perfect world, what would be the correct solution to this problem?" And if time and money permits, go after that solution. Leave the quick and dirty fixes to the novices.
"I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, "Dijkstra would not have liked this", well that would be enough immortality for me."
-Edsger Dijkstra August 1995
Programming
