About two years ago we created an in-house application to send survey invitation emails and track respondents so we could send reminder messages to people who haven’t responded.  The program was necessary because our survey tool, Inquisite, was designed for anonymous surveys where you can’t tell who a person is unless you ask (and they respond).  Over the years, we’ve made the custom invitation mailer program available to clients as a custom solution.  It is still very much an in-house application with a somewhat goofy user interface, and we make some assumptions about the client’s environment that we just couldn’t make if we tried to sell it as part of a commercial package.  Just this week, for example, we’ve had to make changes so it will support SQL Server databases (in-house we’d only used it with Access databases), and we had to add some more stringent communications error checking to support other types of SMTP servers.  Those kinds of things make the difference between an in-house utility application and a successful commercial product.

In his book Zen of Windows 95 Programming (an excellent book, by the way, despite the terrible title), Lou Grinzo makes a distinction between public code (code that other people see) and private code (code that only the original programmer ever sees), and explains how private code has a distressing tendency to become public code—almost 100% of the time.  He makes a very good case for doing things right no matter what.  You may think that the one-shot conversion application you just wrote will never escape from your hard drive, but you’re probably wrong.  You’re going to offer it to a co-worker one of these days, and he’s going to give it to somebody else.  Before you know it, the development team’s going to drop it into the product and a year from now one of your best customers is going to run smack dab into a big ugly bug that resulted from an assumption you made when you wrote the program.  Don’t tell me it won’t happen.  It has.  To every programmer.  At best it’s embarrassing.  Certainly, the development team bears some of the blame for incorporating what is essentially untested code, but a large part of the blame falls squarely onto the shoulders of the original author.

On my white board I have written:

If you don’t have the time to do it right,
where will you find the time to do it over?

Every time I ignore that, I end up regretting it.