You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• More on Staying Current
• Requirements Scrubbing
• On Change
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

Pedro Fonseca sent this, which is a quote from Robert Cravotta: One of the first things I had to internalize when transitioning to embedded design was that my software was invisible in the end system. The end user had no idea it was there—nor did they ever need to. I believe this an essential component of what makes something an embedded system. This had a significant impact on how I defined my worth and my ability to tell people what I did for a living. I laughingly adopted the philosophy of "You know you’re an embedded designer when you have to oversimplify your job description for ‘normal’ people". I found myself just telling people I worked on the Space Shuttle or aircraft because it was too frustrating to try to explain the invisible portion of the system that I actually worked on in those types of systems.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

John Taylor generously offered to send four lucky winners of this month's contest a copy of his book "Patterns in the Machine: A Software Engineering Guide to Embedded Development". This looks to be a really up-to-date volume of interest to all embedded developers.

Enter via this link.

In the last Muse I listed some sources of info I use to stay current. Several readers had additional resources:

Tim Dahlin offered some websites:

John Phillippe has more patience with podcasts than I do:

Matthias Schär sent this:

David Laurence suggested Embedded ML.

Wouter van Ooijen catalogs conferences:

I'm often asked why so many products require software. That electric toothbrush? Well, it's not at all clear to me why a toothbrush needs a microprocessor, but having one means many features can be added. So your digital alarm clock now also shows the temperature and humidity, a TV remote control can accept voice commands, and a sewing machine offers a bewildering array of stitching patterns.

Features that require little in recurring costs are a boon to consumers.

And a bane to developers.

And a wild opportunity to the marking people.

How many times have you heard a sales guy say "I can't sell this thing unless you add this pile of features?" (Writers learn to be parsimonious with words, relentlessly stripping excess verbiage. In that spirit it always seemed to me that the sentence should really read "I can't sell".)

There will always be a tension between what the developers can deliver in a given time and what marketing demands. When we can deliver a mega-line of code in a month, competition will demand it in a week.

But the truth is that while customers and marketers storm the lab with feature demands, there's one feature that's often neglected: shipping. If you don't ship, you can't make payroll. If you're a day late on a Mars mission there's a 20 month penalty before another launch window opens. Miss the Christmas sales season and you're in the red for another year.

In the mad rush to ship we're often forced to trim features. While the more formal name "requirements scrubbing" tries to color this with a bit of dignity, too often it's more of a last-minute slash and burn.

The data is scary:

Almost three quarters of projects scrub 30% or more of the system's planned features. Generally in a mad scramble at the end.

One of the best ideas promoted in agile software development is incremental development. The system always works, perfectly. It might not do a lot in the early days; perhaps a "hello world" is about the extent of the feature set. As engineering progresses more capabilities are added, each tested and proven correct. Cool abilities of low priority are scheduled late in the project. When that ship date does roll around, then, the system might not have everything wanted by the demanding hoards, but it does implement the most important features. And they all work.

The worst engineers are those who tell the boss "we're screwed." That might be technically correct, but is useless. Good engineers give the boss options. "We're late, but..." Having a product that works while missing some features gives options. Ship now. Slip the ship date. Ship and email updates. Ship to beta customers. Oh, that Mars mission? Ship now, and you still have the 8 month coast phase to finish and then upload the code.

The customer is often wrong.

The agile notion of constantly soliciting customer feedback and incorporating that input into a product is a brilliant way to produce prototypes. Prototypes, of course, are poorly-implemented skeletons that mirror a real product. Their function is to quickly minimize risk, which arises from vague requirements, unknown science issues, or from other uncertainties. Prototypes are invaluable when needed but are not required for every product. Maybe not for most.

Engineering teams need to be sheltered from customers when developing the real product. I believe that one of the most important roles of the boss is to act as that insulating layer.

The customer might be an end-user, who, halfway through the engineering effort inexplicably asks for an MP3 add-on to the bottle opener. Or he could be a member of the sales team who thinks that it's nice the thing can open beers, but why can't it also make a salad?.

Iterative elicitation of requirements, while sometimes necessary, is often a substitute for poor requirements analysis. Change does happen, of course, even on the most well-understood products, which is why companies have change control procedures.

Sam Walton was right when he said “There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else.”

When a customer asks for a change, the only proper response is: “Mr. Customer, we love you. We’ll do anything you want. But there will be a cost, perhaps in schedule or dollars. Let me get back to you.” Any other response will yield poor customer service as he’ll be disappointed by the suddenly-late product. Or angry when he discovers that the added MP3 player now means the bottle opener has to be charged every night.

Open communication is key, and that interaction is best if each party has time to think through the implications and the honesty to be clear about what the effect of the change will be on the product.

Change control adds friction to the process, a needed friction. Wild responsiveness is sometimes indistinguishable from chaos. I once delivered a sailboat owned by a younger fellow who had grown up surrounded by electronics. He steered by the course painted on the GPS screen, and just could not understand when I complained that the GPS only knows where we were pointed, not where we want to go. We zigged and zagged all the way down the Chesapeake Bay, getting to Norfolk eventually but much less efficiently than if steered by a steady hand reading the compass.

Set a course, follow it, and change it with forethought only when necessary.

Here's a two-fer.

Anthony Armbruster saw that the Accuweather app on his phone skipped Friday:

This from Neil Peers is fun:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

These jokes are archived here.

Did you hear about the man who got cooled to absolute zero? He's 0K now.

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.