You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• What I'm Reading
• Failure is an Option
• Confutatis Maledictis
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm.

Come to my one-day Better Firmware Faster class near Boston November 1! It will be held at a hotel near Routes 90 and 495, about 38 miles from Boston's Logan airport and 39 from Providence's TF Green. This is the first public version of the class in two years.

This is a very fast-paced (and fun!) full-day course that teaches better ways to produce firmware. I'll show how to drastically cut bug rates and shorten schedules. Plus, I cover technical issues that are unique to embedded systems, like dealing with real-time issues.

There's more information here, and this is the course's brochure.

Seating is very limited so sign up today.

"I like engineers. They build things that are useful and sometimes beautiful -- a brick sewer, a suspension bridge -- and take little credit. They do not wear black and designer glasses like architects. They do not crow." Rose George

Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.

Here's some free PDF conversion software. It can convert PDFs to editable formats like Excel, Word and PowerPoint and also create PDFs from many different Windows documents. It requires no software installation, only an email address where links to converted documents are sent.

What about tools for mobile devices? If you carry a tablet or smart phone, do you know of any great electronics or software-engineering apps for it? About the only one I've found that's any good is EE Toolkit, and that offers only a limited set of features. I sure wish The Art of Electronics were available in an ebook version, as that's the reference I'd like to have on my iPad.

Luis Uribe sent this: A white paper about Intel's 32 nm, 3.1 billion transistor, 12 wide issue Itanium Processor for Mission-Critical Servers. TDP is 170 watts! It would make a great toaster.

We all want to push the digital as close to the real world as possible, without any of that annoying analog stuff. These folks built an FM radio with no analog and no RF section - the antenna goes straight into a Xilinx Spartan 6 FPGA!

Engineers make $160k at Juniper Networks. And they even do really well at, of all places, Walmart.

This month the on-line health exchanges melted down. From what I read, the contractors involved generally have a long history of poor performance on software projects. According to the Standish Group's Chaos report zero percent of software projects that cost more than $10m to develop are deemed successful.

I guess the good news is that things can't get worse.

Zero percent doesn't mean zero, of course, but successes are in the noise.

"Successful" means a project delivered mostly on-time, on-budget with most of the promised features. Only 38% costing under $500k are considered successful.

The data mirrors my observations of firmware development. Few 4KB 8051 programs fail to live up to expectations. Scale that to 32 MB of ARM7 code and the odds of getting anything working remotely like the marketing dweebs originally expected are small.

Especially horrifying is the number of abandoned projects. I don't know how many development efforts were in each dollar ranking, but for guestimation purposes let's assume the average size ran about $2m. The 21% of the 35,000 projects rated as failures equal some $15b in work tossed out the door, equivalent to about 100,000 squandered person-years of effort every year. And that's just for the surveyed programs, which are a bare fraction of all software development going on world-wide in any given year.

We're not doing well.

Something like half of the programs gave customers less than they'd been promised. An editorial in Windows magazine complained that they evaluated a number of shrink-wrapped programs... and 17 in a row did not live up to the promises on the box.

Few industries thrive when they alienate the customer. Software is different than most other products, of course, as consumers simply don't know if the shiny widget seducing them from Wal-Mart's shelves will actually work as promised - or is a lemon. How do you know if that DVD player doesn't read older disks reliably? Or if the software shuts the engine down when the tank is under a third filled (as happened on a BMW)?

But the 'net is the great equalizer, and consumer sites which let readers rank products will eventually force vendors to provide products that meet -- and exceed -- the promises made in the glossy ads.

According to some sources firmware doubles in size every 10 months, which suggests that eventually even Brookstone's smart coffee spoon's code will eventually eat all of the resources of a 500 MHz ARM with half a gig of Flash. But will it ever hit the shelves? Will it work correctly?

Marketing can take their share of the blame for exploiting the low-recurring cost of software by adding every conceivable feature to the simplest of products. Consumers are at fault, too, for their (uh, our) sheep-like pursuit of whatever goodie Madison Avenue plasters across the billboards and TV screens.

But if we developers don't adopt better processes to bring in big projects on-time with reasonable functionality, our jobs will be at risk.

Software engineering is a developing field; it's only about 60 years old, and we're still learning a lot. There's a lot of excellent research going on in this field, and new and clever ideas emerge all of the time. But the average firmware person reads one technical magazine a month, and one tech book per year. How can we keep up with this field, how can we learn how to tame software projects, if we're not deeply engaged with new developments?

"Cessna 47 Quebec, turn left towards Mitchellville."

"Cessna 47 Quebec, roger," the pilot replied.

A few minutes later the air traffic controller more insistently repeated his command. The plane was approaching restricted air space near Washington, DC.

"47 Quebec, roger."

Radar tracks showed the plane was still bearing in on the no-fly zone. Exasperated the controller fairly barked an order to turn immediately, now giving the pilot a compass course. Shocked out of a mental fog induced by the vibration, noise and an assumption everything was OK, the pilot made the course change.

This was in 1984. I was the pilot.

I had been approaching Andrews Air Force base, home of Air Force 1, from Baltimore. With not much experience in the Cessna 172 I had been busy playing with radios and navigation gear, rather than listening closely to the controller. I'd heard a name other than Mitchellville, and was somewhat puzzled as the plane was already headed for that destination. Why was this fellow asking me to change course to a destination that was dead ahead?

I'd presumed he was confused, not me. Him, a controller with decades of experience, compared to my paltry few hundred hours as a pilot.

As an engineer I'm a great believer in the power of technology to solve problems. But there's always a person somewhere in the loop, and we are imperfect creatures operating in a world where there's less margin for error every year. A hundred years ago people operated horse-drawn vehicles at 10 MPH - and crashed. Today we zoom down the road at 100 feet per second, hanging inches from each others' bumpers while chatting on the cell phone and eating a Big Mac. One second's inattention and someone dies.

Mistakes stem from too little sleep or not reading the instructions. Sometimes our equipment confuses us, or one unit displays something a bit different than another, resulting in a bit of head-scratching as our vehicle propels us at breakneck speed through the air or down the highway.

We technologists, designing systems for use by flawed humans, must always assume the user will do something stupid, or will be tired or confused. A hospital engineer told me how on one IV pole he spotted three infusion pumps... all with inconsistent interfaces. Each emitted a different set of beeps in response to changing patient conditions. Imagine the poor intern, 24 hours into a shift, trying to understand what's happening as these things wail and the patient is crashing.

Though our system may work perfectly, accidents will still happen when our user is befuddled. Perhaps the next great arena is developing better machine/human interfaces. Towards that end I highly recommend Don Norman's book The Design of Everyday Things. In it he shows how we haven't even mastered the art of designing intuitive doorknobs. How will we manage much more complex embedded devices.

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 intents of this newsletter. Please keep it to 100 words.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

If the odds are a million to one against something occurring, chances are 50-50 it will. Anonymous.

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .

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.