Principle of exhaustivity in real life problem solving
Are you thorough? Have you thought of all possibilities? Are you sure you have not missed anything?
We face these questions often around us with varying levels of anxiety, concern or barely suppressed impatience.
The affirmative answer is in what we call exhaustive thinking and action. We need it often while we go through our lives. Though the thoroughness is needed time and again, it is generally an ignored and apparently mundane ability.
For decades we solved problems that seemed unsolvable, but when we found what magical power of solving a complex problem such a simple ability of exhaustive thinking can have, we had no hesitation in identifying it as a Principle of Problem Solving that can be applied consciously with great effect in many future problem situations.
This was the first abstract problem solving resource we became aware of and that point was the beginning of our exploration into the fascinating and generally ignored area of problem solving as a separate stand-alone discipline of study and practice.
Principle of exhaustivity
It simply states,
Think of all the feasible possibilities and take all feasible actions systematically.
Case example of principle of exhaustivity in action
It was just another day when the DM (Decision Maker), who was the chief of a large Telco unit invited the DA (Decision Analyst) in a meeting with his team of computer software specialists consisting of two in-house experts and two software specialists from the firm executing the project . The objective was to discuss various issues before changing over from the existing telecom billing software system to the modern and sophisticated new billing system fine-tuned over long past period.
The modern Telco billing software was large and complex that formed one of the main pillars of successful Telco operation.
As charging the millions of customers and taking their payments with associated accounting were the main functions of the software, any error in the software would have been catastrophic for the Telco.
The old billing software was in use for many years and by then could be considered as a benchmark of accurate charging and payment accounting. Through the years its errors were gradually reduced to an acceptable small residual value. But the passing years also resulted in its inevitable obsolescence like any other thing and it needed replacement.
Apart from the labour of building the new sophisticated software the last crucial task was to ensure that it contained least amount of errors. It was and is a law of creating software that it will invariably contain errors that have to be minimized. This task is carried out by repeated testing against some benchmark. In this case the benchmark was the old software.
The first question the DA asked, “Have you completed the parallel run?”
In a parallel run of a Telco billing system all the bills of the million odd customers were to be generated from both the old and the new software systems, and were to be compared using another simple software (comparing million pairs of records needs to be automated). Mismatches were then taken care of by tuning or correcting the new software and the process was repeated again. Usually two parallel runs were performed during the bygone days.
As the whole set of new bills were checked against the old bills that were supposed to be correct, the correctness of the new bills could be assured to a high degree. This was a crucial process towards the success of the changeover.
That day the DA was surprised when the in-house expert responded, “No sir, we won’t have any parallel run. We have already done a series of tests on the software but we don’t have computer resources to conduct a full-fledged parallel run. Instead we will conduct the whole system test on 23000 customers.”
To the old-fashioned DA the idea was appalling. With a trace of incredulity in his voice he asked, “But what is your assurance of correctness of the bills? How can you ensure the correctness of a million bills by checking only 23000 new bills against corresponding 23000 old bills?”
There was a brief silence and the dumbfounded DA was at the point of getting up when the in-house expert played the all-important card, “Sir each of the 23000 bills we selected represents a unique customer profile.”
Profile of a customer consisted of name, address, account id and such other parameters that did not affect the charging at all. But a customer profile would also contain a number of other parameters each of which would affect the charging according to the business rules of the Telco.
These charging parameters could have different values for different customers. For example, an individual customer aged more than 60 years would be considered as a senior citizen and might be charged at a reduced rate.
If you could select and test one customer profile of a senior citizen for correctness matching, effectively you test all the profiles of senior citizens among the million customers.
The DA understood the logic and in a flash visualized the solution to the apparently unsolvable problem.
Believing in fail-safe practices, he first spelled out verbally and then wrote down the steps to be executed by the software team clearly and precisely. “In two days we will give you the results”, assured the software team.
That was a good team and true to their words, they informed the DA after two days, “Sir after we have done what you told us, our assurance of correctness has gone up from zero to 95%. And the number of erroneous profiles that we could not test is now about 20000. ”
The DA asked, “Do you have time to test the rest of these customer profiles not mapped?” The software specialist replied, “No sir, we can test only 1000 of these remaining profiles within the target we had set.” “Okay, you select those 1000 using statistical random sampling method then”, the DA made his second recommendation.
He knew that the statistical random sampling method was heavily used in marketing and other activities where the entities to be covered were too many for cost-effective checking with the given resources.
After this short second stage of testing, the software team had devised an ingenious and brief third and final test. The final result achieved was more than 99% assurance of correctness.
In the beginning it was zero, that is, none had any idea of how many bills from the new system would come out erroneous.
The changeover went through smoothly with negligible customer complaints. It was adjudged as one of the best changeovers among all units of the organization.
As the in-house software expert mentioned “23000 unique customer profiles”, the DA immediately assumed that this set though unique was most probably not comprehensive. The 23000 customer profiles won’t map onto the whole set of million customers. Most people ignore the essential requirement of exhaustive approach as a rule. It is in human nature.
He was more or less sure that the software team must have missed this important step, specially because the team couldn't assess their assurance of correctness measure.
Thus confident with his reasoning, he spelled his steps in the first recommendation as,
- Step I – Identify all the parameters that can affect charging of a customer – identify fully and exhaustively.
- Step II – Identify all values that each such charging parameter can take – identify fully and exhaustively.
- Step III – Now enumerate all possible combinations of the valid values of the charging parameters – fully and exhaustively.
He ended saying, “Now you should get the comprehensive set of unique customer profiles. Theoretically these should represent or perfectly map onto your million customer profiles. But in reality you would find a portion of your million customer profiles still unmatched by any of the unique profiles you have selected as representative profiles. This will happen due to errors accumulated over the years."
Indeed, following this water-tight exhaustive approach, the number of unique customer profiles jumped from 23000 to 41000 but still this set couldn’t cover the full set of million customers as predicted.
In any major real life activity, one of the most important parameters to ensure is assurance of success or assurance of accuracy.
The technique of selecting representative unique set of customer profiles from a much larger set of profiles was found to be the abstract technique of Equivalence class mapping. Each of the unique profiles represented an equivalent class or set of many profiles with same combination of charging parameter values.
This was the key technique used by the software team, but the crucial nearly invisible principle missed was the principle of exhaustivity.
Furthermore, using the systematic enumeration technique, exahustivity or comprehensiveness was assured. Depending on the problem situation systematic method of enumeration would change.
The principle of exhaustivity along with the other two techniques formed the first set of resources in the nascent discipline of Problem Solving. Once formed with clear-cut definition and how it can be used, any such resource can later be used for solving not just one but a wide range of real life problems. More importantly, once this possibility of abstraction and wide-range use of a problem solving resource is perceived, the pool of such resources along with how to use the resources should grow quickly over the years to a large resource pool powerful and versatile enough to be used with confidence in any real life problem situation.