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
Recent Comments