I have always thought that debugging is the most challenging of all engineering skills, and that the hardest part of debugging is to know when to follow your hunch and “go with your gut”, when to go where the data leads you despite your gut feeling, and when to go counterintuitive, regardless of your intuitive feelings. In retrospect, of course, after the dust, electrons, and bits have settled, it's possible to say which path would have been the right one, but deciding in advance, well, that's another story.
I was reminded of this when I read an interview in the Wall Street Journal (August 12, 2008) with Eduardo Castro-Wright, the CEO of Wal-Mart (don't even ask why I was reading this piece). Asked about any mistakes he had made, he answered: “. . . . I would have done things [change] faster, which is counterintuitive. . . . I'm an engineer by training so my physics comes back. An organization is something very solid and when you apply a lot of heat to change it, it becomes fluid. You want to make sure that you don't keep it fluid too long, because liquids move in many directions that you might not have intended.”
That's certainly an interesting analogy, and a perspective that indeed does run contrary to what many of us are taught, or have learned, about making change happen!
Of course, there are many times when the intuitive knowledge you've built up over the years serves you well. Good intuition helps you cut through a jungle of data to see what that data both reveals and obscures, or to feel when the data doesn't make sense and is misleading you due to a faulty test setup, a bad probe, or any incorrect assumption(s) you are making, for example.
There are times when counterintuitive ends up as the way to go. For the first several years of the Apollo moon program, all systems engineering was based on a landing by backing down and parking the third stage, with the capsule at the top, on the moon; the return would be done by using the third stage as the lift-off vehicle. One engineer, John Houbolt, investigated and championed the alternative approach of using a lunar orbiter and an associated lander, with the lander being a very odd vehicle which could only function in the low-gravity, no-atmosphere lunar environment.
Although this counterintuitive approach eventually won out, it was not an easy technical or technopolitical battle. It was burdened with many serious unknowns and risks, although now it seems to us to be very sensible and no big deal. At the time, however, the detailed analysis at NASA showed that the technical cost, benefits (weight, for example), and risk factors (such as a lunar-orbit rendezvous) of the lunar orbiter and lander approach did not produce a clear-cut benefit at all; in fact, in many ways, it seemed inferior. (For more on this story, I recommend the fascinating book Apollo: The Race to the Moon by Charles Murray and Catherine Bly Cox.)
There's an old saying that your get good judgment from experience, and you get experience from bad judgment. There's a lot of truth to that clever phrase. And so far, no one has figured out how to speed up the cycle, and there's no magic pill that will short-cut the learning process. To make it more difficult, many situations are not forgiving of any sort of iterative learning, and you have only one chance to get it right.
-x x x-