Plan for the best or plan for the worst?

Colima Volcano shows a powerful night explosion with lightning, ballistic projectiles and incandescent rockfalls; image taken in the Comala municipality in Colima, Mexico December 13, 2015.


I recently had to modify existing code to enable results to be published from a data guard primary database to an active standby database in real time. The change involved adding a piece of code to perform a checkpoint on the primary when the code completed.  This would immediately post the changes to the active standby.

The third-party vendor of the code preferred to have the checkpoint creation executed by a trigger when their code wrote to a log table. No problem, right? My only concern was that if the log table was used to store ‘failure’ messages as well as ‘success’ messages . Adding some additional code in the trigger could check for and fire only on ‘success’ messages, though. I thought this was the plan until I heard that the log table only stores ‘success’ messages. Finally, I was asked to put a delay of two minutes in the trigger before the trigger code was executed.  I started getting suspicious because there is something wrong when you have to forcibly delay the execution of code. When I asked why, I was told that the log table record was inserted at the start of the process and not the end and the delay was needed to ensure the process completed before the trigger executed the checkpoint. It then became clear why they wanted to have a solution that involved me making code modifications and not them.

To recap, the code inserts a ‘successful completion’ message as the first step of the execution, then the trigger fires, waits for two minutes, and does a checkpoint to publish the results to the standby. This is done regardless of the code outcome.

The thinking that went into writing this code is what I refer to as ‘planning for the best’. This is the mindset that if the code is written right, it can’t possibly fail. Code writers that have been in the business for more that a few years know you cannot plan for everything, so they tend to write code with the ‘plan for the worst’ mindset. This involves writing exceptions and error handlers into the code.  As such, the code is more robust, adaptable, and less prone to failure or having to add tweaks such as delays to make it work well. I almost got whiplash from all the head shaking I did on this one.  Just saying.