feature article
Subscribe Now

The Donkey and the Engineer

“Freedom!” — Mel Gibson, Braveheart


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.  

Leave a Reply

featured blogs
May 5, 2021
New 5G infrastructure is powering smart city projects worldwide; explore the importance of IoT security for smart city solutions in public safety & logistics. The post How 5G Networks Will Accelerate Development of Smart Cities appeared first on From Silicon To Software...
May 4, 2021
What a difference a year can make! Oh, we're not referring to that virus that… The post Realize Live + U2U: Side by Side appeared first on Design with Calibre....
May 3, 2021
As a NASA flight enthusiast, the idea of unmanned aerial vehicle systems (also known as drones) sounds like a lot of fun. A good example of how fun drones can be is through drone racing'¦yes you read that right'¦ drone racing! However, apart from how fun they can be, drones...
May 2, 2021
https://youtu.be/1HEd6JCriCQ Made in Groveland CA (camera Carey Guo) Monday: Package Assembly Design Kits Tuesday: Rapid Adoption of the Arm Server-Class Processors Wednesday: Arm V9A Thursday:... [[ Click on the title to access the full blog on the Cadence Community site. ]...

featured video

The Verification World We Know is About to be Revolutionized

Sponsored by Cadence Design Systems

Designs and software are growing in complexity. With verification, you need the right tool at the right time. Cadence® Palladium® Z2 emulation and Protium™ X2 prototyping dynamic duo address challenges of advanced applications from mobile to consumer and hyperscale computing. With a seamlessly integrated flow, unified debug, common interfaces, and testbench content across the systems, the dynamic duo offers rapid design migration and testing from emulation to prototyping. See them in action.

Click here for more information

featured paper

Compact. Precise. Connected. Increase productivity with intelligent edge computing.

Sponsored by Texas Instruments

Smart devices in factories and buildings are getting smaller and more capable, with enhanced real-time control, robust connectivity, and configurable web services. Read about new processor technology that is unleashing the true potential of Industry 5.0 and the Internet of Things.

Click here to read more

featured chalk talk

Using the Graphical PMSM FOC Component in Harmony3

Sponsored by Mouser Electronics and Microchip

Developing embedded software, and particularly configuring your embedded system can be a major pain for development engineers. Getting all the drivers, middleware, and libraries you need set up and in the right place and working is a constant source of frustration. In this episode of Chak Talk, Amelia Dalton chats with Brett Novak of Microchip about Microchip’s MPLAB Harmony 3, with the MPLAB Harmony Configurator - an embedded development framework with a drag-and-drop GUI that makes configuration a snap.

Click here for more information about Microchip Technology MPLAB® X Integrated Development Environment (IDE)