By Jack Ganssle

It's (Not) a Poor Craftsman Who Blames His Tools

Published - 3/19/2007

The Embedded Systems Conference is nearly upon us. The San Jose 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 do one on embedded disasters that tries to be fun and entertaining. 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 tools 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!