Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 287, July 6, 2015
Copyright 2015 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
   Jack Ganssle, Editor of The Embedded Muse

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

Contents
Editor's Notes

Trillion dollar order

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.

VDC is doing their annual survey, and are offering a pretty amazing $30 Amazon gift card or Red Cross disaster relief donation to everyone who participates. The survey is here.

Quotes and Thoughts

"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

Tools and Tips

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:

Your idea about tie-wraps one scope probes reminds me of something I have taken to doing here…

I put a tie wrap around the 4 scope probes that belong with a scope (or the two probes that belong with a multimeter) – about 3 inches from the instrument end works well.  People used to "borrow" a single probe from a set and not return it… but no-one feels right borrowing the whole lot!  All our sets remain complete and with the instrument now :)

 

Freebies and Discounts

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

Xprotolab

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.

Casstor is offering Muse readers half-off on their LogFilter program that analyzes big log files. For the month of July enter coupon code GANSSLE to get it for $4.99.

On Bad Habits

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.

Software By The Numbers

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:

Processes used
Worst
Median
Best

No design inspections
No code inspections
No quality assurance
No formal testing
30%
40%
50%

No design inspections
No code inspections
Formal quality assurance
No formal testing
32%
45%
55%

No design inspections
No code inspections
No quality assurance
Formal testing
37%
53%
60%

No design inspections
Formal code inspections
No quality assurance
No formal testing
43%
57%
66%

Formal design inspections
No code inspections
No quality assurance
No formal testing
45%
60%
68%

No Formal design inspections
No code inspections
Quality assurance
Formal testing
50%
65%
75%

No Formal design inspections
Code inspections
Quality assurance
No formal testing
53%
68%
78%

No Formal design inspections
Code inspections
No quality assurance
Formal testing
55%
70%
80%

Formal design inspections
No code inspections
Quality assurance
No formal testing
60%
75%
85%

Formal design inspections
No code inspections
No Quality assurance
Formal testing
65%
80%
87%

Formal design inspections
Code inspections
No Quality assurance
No Formal testing
70%
85%
90%

No Formal design inspections
Code inspections
Quality assurance
Formal testing
75%
87%
93%

Formal design inspections
No code inspections
Quality assurance
Formal testing
77%
90%
95%

Formal design inspections
Code inspections
Quality assurance
No Formal testing
83%
95%
97%

Formal design inspections
Code inspections
No Quality assurance
Formal testing
85%
97%
99%

Formal design inspections
Code inspections
Quality assurance
Formal testing
95%
99%%
99.99%

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.

Jobs!

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.

 

Joke For The Week

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 With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

About The Embedded Muse

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. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information.