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
• More on VMs
• Poor Craftsmen Do What?
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

The average firmware teams ships about 10 bugs per thousand lines of code (KLOC). That's unacceptable, especially as program sizes skyrocket. We can - and must - do better. This graph shows data from one of my clients who were able to improve their defect rate by an order of magnitude (the vertical axis is bugs/KLOC) over seven quarters using techniques from my Better Firmware Faster seminar.

"For a long time it puzzled me how something so expensive, so leading edge, could be so useless. And then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match." - Bill Bryson

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

Robert Smallwood is the lucky winner of last month's contest; he got a Freescale FRDM-KL25Z development board.

This month I'm giving away a Raspberry Pi 2 Model B. The contest will close at the end of March, 2016. It's just a matter of filling out your email address. As always, that will be used only for the giveaway, and nothing else. Enter via this link.

Matt Chernosky wrote:

The Boston Embedded Systems Conference is just over a month away. The convention center will be packed with exhibitors and attendees. A thousand or so will attend the program sessions, talks by fellow engineers about new technologies and different ways to develop embedded hardware and software. Most are deeply technical and serious.

But not all. I'm doing one on embedded disasters. For tens of thousands of years people have passed knowledge from generation to generation via stories, rather than web sites and the written word. The human brain seems predisposed to remember stories far more efficiently than we retain formulas. The lore of disaster is so compelling that I use anecdotes to help drive the lessons-learned home.

One of those lessons is about the danger of abusing our tools. Space missions have been lost due to poor version control, an astonishing fact considering how well-known that problem is, and how easy it is to solve.

Then there are languages. C code is usually buggy compared to some alternatives like Ada. Compilers happily accept constructs like:

********************i=0;

... even though no human on the planet has a clue what that means. Compilers happily swallow:

if(a=b)do_something();

... whether that's correct or not, probably without even generating a warning.

"Good" C code usually runs a 5 to 10% error rate post-compile, once the syntax errors have been removed. Ada programs are about an order of magnitude better. These are typical numbers experienced in practice, not quantities that are indicative of the languages themselves. With the right tools and discipline C bug rates can approach those of Ada. Fact is, few developers employ those tools or rigor.

Sometimes people mistake my comments about C as a condemnation of the language, rather than a complaint about how we use C. So I expect, once again, a flurry of emails with comments like "It's a poor craftsman who blames his tools."

It's a poor craftsman who blames his tools. That phrase sounds wise and profound. It's wrong.

Perhaps Noah could build an ark with nothing more than an adze. Few boatbuilders since have managed such a feat. Today's boat shop is packed with tools, each one exquisitely-designed to fulfill a particular task. Take those away and the skilled builder will find his productivity crumble.

That same craftsman has a variety of choices in tools. He could select a $100 Sears quarter-horsepower table saw or a $2000 5 hp Delta Unisaw. The former can barely cut a straight line; the latter sports so much accuracy it's easy to slice a shaving 1/32" thick from a long board. The Sears model might get through a two inch hunk of teak -- in a week -- while the Delta will rip the same board in seconds.

There are some, a very few, extremely-talented boatbuilders who can accomplish miracles with a nearly-empty toolbox. Not many, and all of those are starving, rendered irrelevant by better-equipped workers who produce wonderful products faster and therefore cheaper.

Tools matter. Bad ones slow us down. A compiler that frequently miscompiles will bring a project to its knees, no matter how skilled the developers may be. Though tools won't turn an amateur into a skilled professional, good ones make everyone more efficient.

It's a demanding craftsman who blames his tools. And then he discards the bad ones, sharpens those that are dull, and adds additional ones where a need exists.

C is the community's lingua franca, and will be for a long time to come. Like every language, it's imperfect. The true artisan uses additional tools to help him create great code efficiently.

Don't, and your product might end up in one of my Powerpoint slides!

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.

Apple's new phone lacks backdoors and has a hack-proof OS:

Advertise in The Embedded Muse! Over 25,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.