I can't tell you how much time is wasted, and how many times I've been irritated by people band-aiding problems because it's short-term easy. In the long run, most band-aids are going to end up costing you more than if you just bit the bullet and fixed the problem in the first place.
3) Fix the problem, not the symptom
Even better, redesign your system so that the problem isn't even possible. You can divide folks into two schools of development thought (gross generalization alert!). One group says do the easy implementation up front, so we can have something working now just like in agile development. The other group says 'agile' means doing the simplest thing that will meet what we actually need to do, and part of that is to not have a system with 10 single-point-of-failures - lets spend a bit more time and make the design of something that wont permanently suck. This may or may not actually be outside the scope of "do the simplest thing that will work" but... well, in this not-so-hypothetical example (one I see regularly in my day job) it turns out that if you want your company to stick around for more than 5 or even 10 years that perhaps you don't want to paint yourself in a corner in the first year of business.
One note - there are times that other rules trump this one. (a tribute to Noah Falstein of
the '400 project') There are some reasons to fix a symptom rather than the real problem.
For instance, perhaps the real problem isn't known and no amount of clever debugging can turn it up. At the aforementioned day-job with verio we have a lot of OS modifications - custom kernel work done by some really smart guys I work with. Sometimes our mods don't play well with other stuff and debugging an issue can take weeks, or in a few cases, months. If there is an easy way to avoid the bug (e.g. keep the server from crashing due to vnode-locking issues in a copy-on-write filesystem for instance) while the bug is really being fixed, then by all means, put the band-aid on and then fix the real problem with the time it bought you.
I guess what I'm saying is that sometimes the choice of a band-aid is probably about weighing the costs of doing nothing, the relative ease of the band-aid, the relative ease of the real fix etc. One of my other entries on this blog will be about understanding the business of your business so that you can more effectively make these kinds of decisions.
Anyway, the real point I'm trying to get across is that your desire should always be to fix the real bug. I've worked with people in the past that were oblivious to this concept and they spent their time constantly putting out fires rather than redesigning their systems to make the problems not happen. It is irritating to me to see the lack of concern for "oh, we have a job set to reboot that server every night or it crashes too much"....
Next up: part 4 - "Your Field - Love it or Leave it"
