A company had been developing for two years, by a small team of programmers, an Object‐Oriented program for their Management and Information System, but the system was too slow and occasionally would “crash” the computer for no apparent reason.
To solve this problem they engaged the services of a consultant from a company using the Straight Path Analysis methodology, expecting that the program would be cured of its defects within 2 months.
When the consultant arrived, he was welcomed by the Technical Director, saying, that the Managing Director of the company was about to leave for the USA to attend an Object‐Oriented Design conference and that he wants to have a brief talk with the consultant before he leaves. “The MD is busy at the moment, but will want to see you as soon as he is ready”, said the Technical Director. “In the meanwhile you can have a look at the program at the desk over there”, and with these words he showed the consultant the desk with a computer.
Having only 10–15 minutes before the meeting with the company MD, the consultant wanted an answer to only one question: “What does the program do?”. And he printed out the input data, and the output data, and compared them. They were the same. Then he repeated this with different inputs. And in all the tests the inputs and outputs were the same. At this moment he was told that the MD is ready to meet him, and was shown the door of his office.
At the office the MD welcomed the consultant and told him that the program uses the latest techniques, that he has written some very clever code, and that the consultant should concentrate on some particular areas of the program.
“But what did you want to achieve by this program?”, asked the consultant.
“I wanted to make it Object‐Oriented”, replied the MD.
“But what is this program supposed to do?” asked the consultant again.
“You are talking cross‐purpose”, said the MD, “I suggest you concentrate on the areas I mentioned before. I shall be back on Monday. In the meanwhile, if you have any questions, the Technical Director will be at your service. He knows the program very well”.
The MD's answer that the purpose of the program was to make it Object‐Oriented has confirmed the consultant's hypothesis about the program, and having returned to the computer he removed the Object‐Oriented program by passing the data between the database and the user interface directly without using the Object‐Oriented program. And the system started working without any delays and crashes.
Having tested the corrected system, the consultant went to the Technical Director and demonstrated to him the system working without the problems the consultant was expected to solve.
“I see the system is working, but you have been here less than an hour. What have you done to make it work?”, asked the Technical Director.
“I have removed the Object‐Oriented program completely”, said the consultant and showed to the Technical Director what he did.
Then he explained to the Technical Director that the program was not doing anything useful, except for introducing delays and occasional crashes. It was an identity function f(x) → x, like drinking water with two glasses. First you fill one glass, then pour the water from it into the second glass, then from the second glass back to the first glass, then drink it. This is slower than drinking directly from one glass, and it is still the same water.
Having understood what happened, the Technical Director said, “Yes, I understand it all now. But now I have an even bigger problem: I have to tell our MD that the program, which was his brainchild, and on which our team of programmers worked for 2 years was not doing any useful work and that it was a total waste of time”.
“It was not a total waste of time”, said the consultant, “The MD has learnt Object‐Oriented Programming, and created and trained a team of programmers. This is a valuable company asset which he will be able to use in the future”.
On the Monday morning that followed, the MD was back and had a meeting with the consultant and the Technical Director. He was given the good news that the problems with the Management and Information System had been solved, and was explained what was the problem with his Object‐Oriented program.
And in the afternoon of the same day, as the consultant passed near the half‐open door of the MD's office, he caught a glimpse of the MD pacing to and fro and repeating the phrase “What a fundamental error of judgement!”.
The MD was a very bright young man who was the founder and the main shareholder of the company. There was none above him, none to blame, sack or demote. He made an error of judgement, he accepted it, and it became part of his learning experience.
But what would have happened, if the program was not the brain‐child of the MD (who owned the company), but of a hired employee, like a Project Leader, as it happens in bigger companies?
The consultant would have been given some other problem to solve and asked not to tell anybody about his findings.
The error in the above case was due to the MD, who having become enthusiastic about the then fashionable Object Oriented Design, had used this methodology without having asked himself what was the purpose of the program that he and his team of programmers set out to develop.
The program was indeed object‐oriented, it accepted text as input, built out of it different objects and then used these objects to build the same text as it received on input and outputting it without any change. It did nothing useful, except causing unnecessary delay and occasional “crashes” due to internal programming errors.
While this case is unique in its clarity and simplicity, many projects fail, or run over the budget, not because of “technical issues”, but because of lack of clarity of the purpose of the project and how this purpose is to be achieved. And while a range of methods, techniques, and tools have emerged to deal with this problem, knowing how to use such aids does not provide the ability to distinguish the essential from the superfluous, and the real purpose of the project from implementation details.
And this happens in computer programming, an area of human activity based on mathematical logic and precision. But what happens in “politics”, an area of human activity ruled by raw emotions: pride, vanity, greed, fear?
And, while in software development errors of judgement lead to loss of time and money, in politics they lead to deaths of millions and destruction of cities.
So, how to avoid and detect fundamental errors of judgement before they cause damage and to correct them once detected?
On the face of it, it is surprisingly easy. All one has to do is to ask some simple and obvious questions, like: “What is the purpose of this project?”, or “What is the purpose of this war?”.
But to be able to give the right answer to such question is surprisingly difficult. And the difficulty is being able to see the issue not from inside of one's own ego, but from outside of it, looking at the bigger picture.
One also needs to be free from emotions which cloud the mind. And this is the real BIG problem that has plagued Mankind from Times Immemorial and to which still no solution has been found.