The Donkey and the Engineer

The Donkey and the Engineer
-----------------------------------------
Freedom is a good thing, right? Whether it’s political, design, or economic freedom, we generally believe that more freedom—more flexibility to make choices—is unequivocally a good thing to have. You can never have too much freedom.
But is that really true, even for design engineers? At the far end of the political spectrum, extreme freedom is called anarchy: the complete absence of control. And most people use the word anarchy in a bad sense, so maybe there is such a thing as too much freedom. Total economic freedom, such as the type Ayn Rand espoused, also tends to divide opinions. Some see it as the triumph of personal will and responsibility, while others view it as economic oppression. Entire governments have been formed (and toppled) on such questions.
Esoteric political ranting aside, how much freedom do you actually want as an engineer? Probably a lot, right? You’d like to choose your chips, your software, your tools, and so on, as you see fit, with no artificial restriction. The most choice yields the best solution, and you’re just the guy to make those choices.
If you sense a setup coming, you’re right. Too much freedom can get you into trouble, and here’s how.
When I’m working as an engineer, I want the most design freedom possible, so that I can choose the best chips, best software, and best tools (for some definition of “best,” which depends on the application). Anything less than that is automatically and by definition a sub-optimal solution, because I had to compromise on something I wanted. Something that I felt would have led to a better product.
But when I worked as a marketing guy, I ran headlong into the opposite way of thinking. I was struck—several times—by customers’ vociferous demands to reduce their design freedom. Huh? What’s this? You want us to remove choices; take options off the table; diminish your design leeway? Yup. Their answers were clear and consistent and well-informed. These people knew exactly what they were saying. They understood the apparent paradox. And they still wanted us to take away their freedom.
But that’s… so… un-American. In actual fact, it was the American customers who most wanted their freedoms abridged. “You’re offering us too many choices,” they said. “Make it simpler. We’re in a hurry.” In other words, they wanted us to make the decision for them. They wanted a price, a delivery date, and a fact sheet—and no options.
Too much choice can lead to “analysis paralysis.” We can spend so much time weighing and analyzing the choices that our decision becomes moot. If the product you’re developing is six months late to market, that six months spent agonizing over the best RTOS or the right way to handle Ethernet interrupts was counterproductive. You’ve got the world’s best-engineered product that will never sell. Sometimes quick and dirty really is the way to go.
Like the donkey placed exactly halfway between two haystacks, we can’t make up our minds. We figuratively starve ourselves to death, unable to make a decision and move on. Good engineering managers recognize this and deliberately reduce the number of options available to their staff. Yes, Virginia, your boss is hiding stuff from you. He wants you to be productive and happy, not dazed and confused.
In my particular case, I was peddling a user-configurable microprocessor. It was, I felt certain, the coolest technology ever. You could actually create your own microprocessor instruction set, adding and removing functions and features until you had the exact CPU you wanted, perfectly suited to your application. Other engineers loved it. It was effective and efficient and opened up endless design opportunities.
And therein lay the trouble. Who has time to design their own microprocessor? Where would you even begin? It didn’t matter how great the end results would be—and they were often pretty great—nobody had the faintest idea where to start or what changes they’d want to make. Should I have four different types of ADD instruction? Maybe… who knows? Should I eliminate the BCD instructions I’m not using? Maybe… but what if I need them later? Hey, maybe we can try cloning an x86 (or 8051, or MIPS, or ARM, etc.) and make our own PCs… And so it went.
The endless possibilities opened up endless tech-support discussions about hypothetical CPU designs that could do this or that. Everyone wanted to know what the best design choices would be (again, for some definition of “best” that changed with the application). And here we got caught in a dilemma: if we tell them they’re supposed to find the best answer for themselves, they think we’re dodging our responsibilities. But if we give them a canned answer and say, “do it like this,” then they ask what’s the point of configurability and why we didn’t built the processor that way in the first place.
It was a no-win situation: their newfound design freedom was either a time-sink or a pointless feature. In the end, most customers made very simple changes to the CPU and called it a day. Looking at it from an engineering perspective, most of the processor’s astounding configurability was never used. All that potential wasted. But the customers were happy, so who am I to complain?
The point here is that there is such a thing as too much freedom. We can have too many choices, and sometimes it’s better not to know all the options that are available to us. It’s different if you’re an academic researcher, perhaps, but for working engineers who have to produce a product to a schedule and on a budget, it’s often better to put the blinders on and plow ahead. Distressing, maybe, but true.
A few things came out of our experiences of extolling the virtues of a very flexible product. First, we soft-pedaled the configurability aspect when talking to managers or executives. They could spot a time-sink a mile away, and they were horrified at the idea of their engineering staff tinkering endlessly in the lab when they should be “working.”
Second, we started making pre-configured versions of the processor. This tidily answered the (entirely reasonable) question of, “if you already know the best way to configure this CPU, why don’t you already do it?” A few canned instantiations eventually satisfied most customer requests and become more popular than the original user-configurable version. Oh, the irony.
Finally, we developed a lot of free software to go with the processor. Because, after all, a microprocessor is just a means to an end. As Theodore Levitt says, people don’t go to the hardware store because they want to buy a quarter-inch drill. They want a quarter-inch hole. We were not only selling customers the drill, we were making them assemble it first.
Newborn babies like to be tightly wrapped, and it turns out most customers do, too. As engineers, we sometimes have to curb our enthusiasm for options, choices, and configurability. Look how popular the iPod became, and it had virtually no user options apart from “play” and “stop” when it was first introduced. Choice can lead to confusion, and confused customers don’t buy product. Make your choice, stick to it, and be satisfied.