Defensive programming: move the concept from art to practice

Few days ago, the nightly regression test suite completely melted.   There were so many errors that I had to schedule a very long conference call and work through the details and determine what happened.

Despite many errors, several distinct themes emerged from the discussion:

– The code did not have good run-time awareness.   Certain changes in the run-time environment (that could occur in the client environment) were simply not detected and caused unexpected behaviors

– The code did not have good error localization techniques.  Error that surfaced in component A was in fact rooted in a problem that occurred much earlier.    The code architecture made it very difficult to quickly find the root cause of the problem.

– Error messages were not descriptive not self-educational.  For example, there is a difference between stating “error happened while transmitting a file’ and ‘error during file transmission.  50 Mb of 100 Mb were successfully transferred.   Remaining 50 Mb will be transmitted when the service restarts in 3 minutes.  No user action required’.

– If the team spent on average 20 hours solving several problems, more than 70% of the time was spent on looking for the root cause.  The diagnostic time was simply excessive, a symptom of a poorly engineered code that does not generate helpful error diagnostic information.

I am a big fan of Code Complete by Stephen McConnell.  One can easily find it on Amazon.com at