Have you ever worked on a project that involved a requirement with an IF statement with several branches and multiple conditionals in each branch? Then the programmer takes the simplest approach and programs it exactly as it was written. Later, there are issues and it becomes very difficult to debug this logic.

I was working on a project recently that involved a complex calculation for the timeliness of a process order. The logic included checks to see if the process order was running (had any jobs started?), to see if any jobs started late or missing required finish times, and more comparisons. I was not responsible for the original implementation, but I was asked to investigate and fix it after the customer had issues with the calculations.

The specification included requirements such as (paraphrased):

• The status will be “DELAY” if any of the following conditions are true:
• the job has not started and the scheduled start time has passed but the latest start time has not passed yet.
• the job is running and it started after the scheduled start time but before the latest start time.
• the job is completed and it finished after the scheduled finish time but before the required finish time.
• The status will be “LATE” if any of the following conditions are true:
• the job has not started and both the scheduled and latest start times have passed.
• the job started after the latest start time.
• the job is completed and it finished after the required finish time.

The more complicated the logic and conditions, the more important it is to expose these details both for debugging purposes and for the user or administrator.

There were several issues I uncovered with the above specification as well as enhancements that I added.

One of the primary issues was the general status of either “DELAY” or “LATE” without indicating which condition was responsible for the status. For example, the customer noticed a process order was marked as “LATE” even though the required finish time had not elapsed. It turned out the process started late, but it was not easy to figure that out with the information provided on the screen at the time.

Consequently, I enhanced the status codes to return more information. There are two basic options: change the status codes, or add a sub-status code with the detailed information.

The typical implementation of conditions and logic look something like this (shown in a SQL-style language but it really does not matter which language is used):

My implementation was actually in SQL since the goal was to reduce the data returned to the client application. You could implement it in the client application, but that results significantly more data transmitted and slows the client application and decreases the available bandwidth for all users.