Don't Trust Your Own Code

Yesterday we had a little snafu at one of the companies I work with.  Some users received duplicate and even triplicate reminder emails.  This snafu was caused by what I consider to be one of the key mistakes when first working on production systems: rookies trust their own code.  By this I mean assuming that code you wrote yourself has the behavior you think it should have and then not guarding in other code against possible errors.  The particular case in question involved two parts: code to identify certain users that should receive reminders and code to format and send those reminders.  The developer had no checks in the sending code to guard against the identifying code providing erroneous information.  In the worst case the sending code would have happily sent a single user thousands of reminders.

Obviously, writing and running unit tests will help but one can’t rely on those to catch everything that might occur once the code runs in the production environment against the production data.  There is always the possibility of overlooked corner cases, configuration mistakes, or operator error (if human input is involved).  So how defensive should code be?  Basically I think it’s almost impossible to err on the side of being too defensive.  So testing whether arguments are of the right type and in the right range is always a good idea.  Making sure to catch exceptions or other error conditions (unless there is some global exception handling in place) is critical to make sure your code returns and users don’t see crud.  Whenever you do something hard (impossible) to reverse, such as sending email to users (or deleting old data), ensure that you don’t do too much of it.  “rm *” checks to make sure you wan’t do that for a reason.  Your code should too.