My favorite marina in Michigan is an eclectic collection of barely-able-to-afford-their-boat boaters and a rotting, self-maintained infrastructure. It’s referred to locally as the Rednect Yacht Club, it’s falling apart, it’s the wonderful people who hang out there that make it worthwhile.
I am pretty sure that the land is disappearing beneath the deck we have next to our dock. This is about a 12-foot square area with a wood deck. Actually, it’s a couple of small decks laid in a mosaic by our dock. Some of these are starting to move around, and they’re no longer all at the same height. As I said this place is falling apart.
One of my fellow marina dwellers recently offered up a large piece of indoor-outdoor carpet to put over the worst parts of this deck. To make it look better, I assume. I think I surprised them when I politely declined, saying I didn’t think hiding the issues was a good move. It doesn’t seem to me that making an uneven surface harder to see is going to make it less likely that you are going to trip over it. Quite the opposite actually.
After thinking about that for a while, it seems to me that is a good approach to life in general, and to software development in particular. Covering over problems never works out in the long run. They just cause bigger problems later. To put it in terms of my deck, stubbing your toe on a ledge that you can see is better than tripping over one you did not know was there.
Lots of development teams prefer to hide their errors rather than resolve them. This is equally true of warnings, they are just errors waiting to happen. This strikes me as insanity, but I see this all the time. In 40 years old software development, I have only worked at one shop that insisted that all of the compiler warnings be out of the code before going to production.
I worked for a company recently on their new application, and I quickly discovered that two different screens in that application showed a client’s address, and those two places showed DIFFERENT values for the same person. It seems that at some point in the past they migrated from one set of tables to hold address info, to another set, and never bothered to eliminate the tables that weren’t supposed to be used anymore. When I asked why they did that I was told when they had previously tried to remove that bad tables they received a lot of errors, so they left them in place. Not surprising, since part of the code still referenced the bad tables.
This would have been horrifying if it had made it to production. If you ever find yourself in a similar situation I implore you to remove the old tables, delete the code that’s not supposed to be used anymore, and then FIX THE ERRORS. It will take longer, and it might be messy, but if you don’t I guarantee they will come back and bite you in a tender spot eventually.