One reason you should clean up warnings

Compiler warnings can sometimes be more aggravating than useful.  We've all encountered them, and learn which ones to ignore in our code.  I think it's best to clean them up, either by fixing the code or suppressing the warning itself.  Suppression should be done with caution and should be clearly documented, of course.

I was finally convinced of the need to clean up warnings at a previous employer a few years ago.  This company has since gone bankrupt, and what you're about to read is one of the reasons why.  It provided a database application to a specific industry, let's just imagine it was widget manufacturers.  The application had a lot of flexibility to it, too much in fact, and was sold to specific widget makers with customizations defined by them.

One day, one of the widget makers called and said they were hitting a bug in the program which caused some of their data to be lost.  We investigated and found the bug.  The developer who owned the code checked in a fix, and we eagerly told the widget maker we would soon have an update ready for them, which we would courier overnight on a CD.

The client received the CD, installed our program and called right away to tell us the desktop shortcut didn't work.  Luckily there were a few technically savvy people at the client's office who pointed out that our program was nowhere to be found on the system where they had just installed it.  Our used car salesman turned CEO was red faced and reflexively told the client the disc we sent must have been defective.  I found out later the client knew better, but it did buy us another day.

We did some digging, and found out what happened.  First, the checkin made by the developer caused a build break.  This also meant he never tested his fix, but that's a separate issue.  The builder kick off a build and as was his habit, ignored the error, because there were so many warnings in the code base.  He never noticed that our main application failed to build.

The next guy in the chain, who owned the installer package, also ignored the warning that the application did not exist when building his package.  Why?  Again, there were too many warnings and he just assumed all those lines flying by were the usual noise.  And finally, after burning the CD, the test team installed the build on a machine which already had an installation.  They didn't test the fix; instead, they simply logged in and made sure the application launched.  Why?  Management routinely refused to buy them the tools to quickly re-image an OS and have a clean system to install, and insisted this CD get out the door before the FedEx office closed for the day.  The same management which refused to buy additional build hardware so that we could build on something other than a Pentium 90 (400s were standard at the time).

While the failures here were numerous, a key component was all the warnings in the code.  They made everyone sloppy and complacent.  If the builder had noticed the application never built, that could have avoided all the problems.  If you go from zero errors and warnings to some, that's a lot easier to notice than an extra message out of thousands.

As a footnote, I have no idea whether the fix worked.  Not only did I quit the next week (I already had an offer elsewhere), but the client cancelled the contract.  The ensuing litigation was one of the things which finally put an end to the software company.