Since I’m in Boston, we have a lot of snow to deal with this winter. The other day I was clearing snow off my roof with a roof rake, and after about an hour for some reason it started pulling to the left when I pulled straight down. I started to compensate by pulling the roof rake more to the right to compensate, but that didn’t really help much. After finally getting frustrated enough to pull the roof rake down and look at it, I saw that one of the support brackets was no longer screwed to the rake, so the blade was unsupported on that side. That’s why the rake was pulling to the left. Had I looked at the rake as soon as I noticed the problem, I would have saved a lot of frustration, and possible permanent damage to the roof rake. I fee we do the same thing with our software tools a lot.
Very often I’ve seen software where the usual reaction to compilation warnings is to tell the compiler to ignore them. There are times when this is appropriate. My favorite example of this is with Java Generics, where it’s very hard to get around some of the warnings for things that you and I know are perfectly safe. Most of the time, though, compiler warnings are indicating a moderate to serious problem, or at least an area where the program might not be doing what you think it is. Eliminating those warnings is an excellent collaborative activity, because we all have experience with different software issues.
So the next time you feel tempted to “ignore the Check Engine” light, spend some time finding out if there’s a more elegant solution than putting tape over it.