Today, I give the rest of the story as it actually happened, then consider some of the astute comments given already.
What the Consultant Did
The consultant was astonished by the programmer's response: "That's not an error. Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."
The consultant understood, which the programmer did not, that a program error occurs when the program does not do what the customer wanted, not what the programmer thinks the customer should have wanted. That was the programmer's first mistake.
The programmer's second mistake was not understanding who his customer was. He seemed to think that the French were the customer, but the actual customer was the consultant.
(NOTE: If the actual customer had been the French, the programmer's action was still wrong, because of his first mistake. If a programmer thinks his customer has asked for the wrong thing, he could, politely, bring this thought to the customer's attention. So, if the French had been the customer, the programmer's third mistake was not bringing his thought to them. And even if the customer had been correctly identified, the programmer's fourth mistake was being rude and arrogant. That's simply not the way to get your point across, especially if your point is that your customer has been wrong.)
What the Consultant Said
"You didn't understand your assignment," the consultant said. "We're trying to simulate the precise formula used in France so we can compare it to the formula used in other countries. It's not a question of right or wrong, but merely of matching the existing French formula."
"Well," the programmer replied, "anyone with half a brain and a smattering of knowledge of inventory theory can see immediately that the French formula cannot possibly be correct, so what's the sense of programming it? Tell them to use my formula, if they want to improve their inventory management."
The management consultant decided to try another approach with the recalcitrant programmer. "That's a good idea. If you're right, I'm sure they'll really appreciate getting a better formula. In the meantime, it will help them to accept the new formula if they can see how it compares with their original one on this data, so I'd appreciate having their formula programmed as soon as you can manage."
"You don't seem to understand," the programmer insisted, "Why should I waste my valuable time on a formula I know is wrong? Just show them my formula and they'll understand."
At this point, the management consultant gave up on the programmer and got himself another one. The French formula was programmed and found to give the claimed results which were, in fact, superior in many circumstances to the approaches used in other countries. It turns out that the programmer's fifth mistake was overestimating the "correctness" of "inventory theory."
A number of readers correctly (I believe) said they would try talking with the programmer. In the actual case, the consultant tried this, but learned that the programmer was not going to listen. Perhaps this was the consultant's fault in the way he tried to talk to the programmer, but in any case, if your employee (and the programmer was, of course, working for the consultant) won't talk with you about a situation, then you have to get rid of that employee. So, attempting to talk is a good approach, in that it gives you essential information even if the programmer refuses to talk.
Other readers warned the consultant to consider his own role carefully, and to consider myriad possible interpretations of what's going on. This is always good advice for a consultant.
Several readers correctly identified one or more of the programmer's mistakes (above). Clearly, someone needs to educate the programmer about what his job is, and how to do it, but evidently the consultant lacked the skill to accomplish that. So, again, the consultant needs to consider his own role, at least for the future. In a similar situation, for example, he might take more care in choosing the programmer and/or making the programmer's task much clearer from the outset.
Those who advised the consultant to get "on the ground" with the inventory application were also on a productive track. In this case, the consultant was in the USA, and meekly accepted the refusal to pay him to travel to France and study the French approach first hand. If the consultant knew what he needed but didn't insist on having it, he made a major consulting mistake. If you insist, but your client won't supply it (time, or access, or money, or whatever), then the consultant should simply resign from that assignment.
Using specific examples rather than simply theory—what a good idea. Both the consultant and the programmer were probably "intuitives" in the MBTI sense, so they kept the discussion on the level of theory, which often misses some crucial data. In this case, if the French formula actually worked in practice, that would have thrown an entirely different light on the discussion.
All in all, the case example seems to have done its job—namely, stimulating an outpouring of darn good advice about consulting and programming.
Now that you have the "whole story," what further observations would you like to make as comments?
When Do You Need a Tool?
1 week ago