Identification via Isolation

Recently I had an interesting conversation with a software developer who was particularly frustrated with the people complaining about the end results of her software program.  At a high level, this software process looked something like this:

These complaints were not her big problem. Taking every feedback seriously, she would delve into her code and later identify that the problems were not due to programming errors or “bugs”. Rather, these problems were originating further upstream from the inaccurate data records which were used as an input to her program. So, her main frustrations were:

1. Why do the database people keep providing incorrect data?
2. Why is programming first to be blamed at?

Issue #1 is a classic process issue known as “Garbage In, Garbage Out”.  And #2 is due to general human tendency. Whenever we see an erroneous result, we tend to dig (or even blame) the step which immediately precedes the final result. 

An ideal and easy way to resolve #1 is to establish the service level agreements (SLAs) among the internal supplier & customer. In this case, the programmer is the internal customer of the database analysts (DBA). So, she defined a clear set of requirements/expectations from the data streams which are the inputs to her programming process. And the DBAs were instructed to achieve those expectations before providing their outputs. The DBAs can develop their own internal quality checks to validate the data and provide those results along with the data-stream to the programmer. In manufacturing world, this is similar to suppliers providing completed inspection checklists and test results with their parts shipments to the next customer.

Issue #2 is a bit complex one to deal with. Here, programmer is up against the general human tendency rather than any logical argument. After some thought, she came up with her own solution. She created a controlled sample of the data-sets by validating them herself first. Then, every modified version of her program was first tested by using that “controlled sample” and the results were analyzed. Now if the new, current data-sets (which were also being modified in parallel) do not produce the same results as being produced by the controlled sample, it is easy to conclude that problem lies in the data integration and not system-level programming. This is what I call, “identification by isolation”.

Situations like these keep reminding me of the importance of root-cause analysis in our daily lives. We don’t need a fancy formal training or certificate in order to become an effective problem-solver. In fact, being humans, this skill is hard-wired in our brain. We need to recognize and sharpen it by using common sense and a focus on resolving the issue, and not just whining about it.