You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• On Bad Habits
• Software By The Numbers
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

This image is a screen grab. I was ordering parts for the boat; $30 of paint, $54 for engine filters. The total: $84 trillion. Didn't sound right to me. This sort of result is absurd, yet all too common in the world of software and firmware.

This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs, like the one above, in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

"People think that computer science is the art of geniuses, but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones." - Donald Knuth

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

Here's a great site for people interested in old technology. This explores the history of oscilloscopes from 1943-1957, giving exemplars of the most important products. It even contains schematics!

How do you perform firmware updates? This is a tough problem to get right, since there are many boundary problems, like power failures, security issues, limited memory, etc. I don't know of any vendors for such code (other than one or two that focus on security, and not the entire range of issues). I have been asked about this a few times recently and really don't have a canned answer. I'm sure Muse readers would benefit from any pointers.

Martin Thompson wrote about an idea in Muse 286:

Congratulations to Kirk Bailey, who won the Saleae Logic Pro!

Another scope giveaway: one lucky Muse subscriber will win an Xprotolab scope this month. This is one of the coolest scopes I have seen. I reviewed one here. The thing isn't much bigger than a pair of postage stamps, has two analog channels and 8 digital inputs. It has an arbitrary waveform generator, protocol sniffer, DMM, and a frequency meter. It sells for only $49.

The Xprotolab is a great experimenter's platform as all of the code and schematics are available. I wouldn't give up my real scope, but what a cool idea!

The giveaway will close at the end of July, 2015. Go here to enter. It's just a matter of filling out your email address. As always, that will be used only for the giveaway, and nothing else.

You can practically read the model number of the phone he's yakking on because his SUV is mere inches from your rear bumper as you both careen down the rain-slicked highway at 55 MPH.

Resisting the temptation to wave a single-digit greeting you sigh in temporary relief as he swerves, without signaling, across three lanes of traffic in a desperate effort to shave five seconds off his morning commute. Instantly, though, another tailgater moves into position, seemingly trying to get you to drive faster despite the mass of drivers only a half-dozen car lengths ahead. In a line in a movie theater this sort of shoving would be socially unacceptable. For some reason it's expected on the roads.

What are these people thinking? Are they really the morons their actions suggest? If so, then some huge percentage of the adult population should be committed to an institution for the criminally insane.

I always figure that most folks are a decent sort, so chalk this aggressive behavior up to their unnoticed acquisition of bad habits. New drivers progress from fear to overconfidence, back to fear after witnessing horrific accidents or their aftermath, to an easy comfort behind the wheel largely untroubled by the potential consequences of this very serious endeavor. Those death-like two-handed grips on the wheel in drivers' ed give way to steering with one's knees while shaving and drinking coffee, issuing an occasional expletive at some other driver's even worse antics.

One of the scariest moments for a parent is when the teenager first takes off alone in the family car with his or her shiny new driver's license. They, too, may drift into similar sorts of bad behavior as they become more comfortable behind the wheel.

Bad habits accumulate, which is why I tried to instruct my kids to think once in a while about their driving. To reflect, to examine and to question their habits. "Do I tailgate? What's the upside? Has my speed been drifting up? Do I roll through stop signs?" Without that sort of self-reflection it's impossible to detect - and take appropriate action to correct - accumulated behavior that makes a mockery of the very serious responsibility of driving.

Such reflection should be a part of all aspects of our lives. "Am I being good to my spouse?" "Am I happy with the way I get angry at the kids?"

In engineering, too, we drift into bad habits. Sloppy documentation, poorly-written comments, and coding shortcuts that, hopefully, usually, probably not soon, may create trouble down the road, are all unacceptable behaviors that don't illuminate any red lights. There's no cop waiting behind a billboard to tag us for writing that awfully-convoluted function. One reason for code inspections is to provide these audits, but there's nothing that substitutes for a bit of self-examination from time to time to root out these habits... and then take corrective action.

Self improvement begins with identifying that which one wishes to improve. All of us need to think though our accumulation of habits from time to time.

I am a huge advocate of using numbers in engineering. Unfortunately it can be hard to find metrics about the industry. Capers Jones' book The Economics of Software Quality is bursting with numbers acquired from thousands of software companies. It's not really a fun read; much is tedious as he compares efficacy of various software engineering methods. He admits the the standard deviations are large. But the numbers do give a sense of the effectiveness of various approaches.

For instance, defect removal efficiency is the percentage of bugs that are removed prior to shipping. Bugs are found at all stages of the engineering process, and one hopes that various filters like inspections would remove all of them before the product makes it out the door. Alas, that seldom happens. A perfect process would yield 100% defect removal efficiency.

Table 4.9 from Jones' book compares how combinations of four activities affect defect removal efficiency. Here are the results:

My takeaways are:

• Yes, standard deviations are large. But the patterns are apparent.
• Given the average defect injection rate of 5-10% (i.e., 50 to 100 bugs per KLOC), to achieve world-class quality levels of one bug shipped per KLOC we have to use quite-disciplined processes.
  

The book has little to say about agile methods, though cites defect removal efficiencies at "<40% to >65%". However, Jones admits there is little data available from which to draw conclusions.

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. There is no charge for a job ad.

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

Jon Titus wrote:

The late Bob Pease, the analog guru at National Semiconductor, used to say he lived at the junction of El Camino Real and El Camino Imaginary.

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.