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

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

The Embedded Systems Conference is nearly upon us. The San JoseConvention Center will be packed with exhibitors and attendees. Athousand or so will attend the program sessions, talks by fellowengineers about new technologies and different ways to develop embeddedhardware and software. Most are deeply technical and serious.

But not all. I do one on embedded disasters that tries to be fun andentertaining. For tens of thousands of years people have passedknowledge from generation to generation via stories, rather than websites and the written word. The human brain seems predisposed toremember stories far more efficiently than we retain formulas. The loreof disaster is so compelling that I use anecdotes to help drive thelessons-learned home.

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

Then there are languages. C code is usually buggy compared with somealternatives like Ada. Compilers happily accept constructs like:


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


… whether that's correct or not, probably without even generatinga warning.

“Good” C code usually runs a 5 to 10% error rate post-compile, oncethe syntax errors have been removed. Ada programs are about an order ofmagnitude better. These are typical numbers experienced in practice,not quantities that are indicative of the languages themselves. Withthe 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 ofthe language, rather than a complaint about how we use C. So Iexpect, once again, a flurry of emails with comments like “It's a poorcraftsman who blames his tools.”

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

Perhaps Noah could build an ark with nothing more than an adze. Fewboatbuilders since have managed such a feat. Today's boat shop ispacked with tools, each one exquisitely-designed to fulfill aparticular task. Take those away and the skilled builder will find hisproductivity crumble.

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

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

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

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

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

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

Jack G. Ganssle is a lecturer and consultant on embeddeddevelopment issues. He conducts seminars on embedded systems and helpscompanies with their embedded challenges. Contact him at . His website is

Reader Response

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

It isn't wrong, it *is* wise and profound; but it seems that s/w engineers don't understand the context in which this wisdom is given.

A true craftsman will not accept an assignment unless he can choose the tools for the job. A true craftsman will always have a large suite of appropriate tools, and will apply the correct tool to the task at hand.

You want a practical example?

If I called my local cabinet maker and said I wanted to retain his services for the construction of a custom china cabinet, but added; “Oh, by the way, you can only use a hammer for this project”; do you think he would accept?

Of course not; if he did, and then blamed the (predictable) result on the hammer restriction, my response (based on the wisdom above) would be “You're the professional, you accepted the job given the restriction, therefore I hold you responsible for the result, and you cannot blame the result on the tool that you agreed to use”.

“It's a poor craftsman who blames his tools”, because the craftsman is ultimately responsible for his selection of tools.

Strangely, I witness s/w “engineers” accepting jobs with equivalently outrageous restrictions all the time (again, with predictable results). A true s/w engineer, will refuse to take on a project if they are not allowed to select the appropriate tools for the job.

– Rennie Allen

Jack Ganssle is correct about craftsmen and tools. Rennie Allen is not. His example borders on some fantasy life. Perhaps on Route 128, or perhaps Silicon Valley, people can change jobs by changing driveways, but that is not what most engineers experience. Yes people can move, but then you end up disrupting your life, leaving friends behind, pulling your children out of school to move, tellling your spouse to change jobs, etc. In other words, not in touch with reality. His example is also flawed. His example, more correctly translated, would have been that one contracts with an engineering shop to write software and dictate that they use a compiler that they know to be full of bugs for a fixed price. In that case one could state that they walked into it with open eyes. The example Jack was making about boatbuilding is correct. And the quality of these new boats is superb, much better than the old hand built boats. Most engineers struggle to convince management about what tools and training they need, and often they are ignored or they don't couch the arguement in the economic terms that will be convincing enough to prevail. I believe that Jack has commented before on the difficulty in convincing “the boss” to spend money of software tools.

–Robert Kits van Heyningen
Portsmouth, RI
VP of Research & Development
KVH Industries, Inc.

Tools + TIME, I'm sure the cabinetmaker would not work to unrealistic deadlines as some of us are forced to!

–Raghu Char
Bangalore, India

So, are software developers craftsmen or engineers? Very few engineers get complete and total say over what tools they use. They probably get to make some input, but by and large companies push for common processes and tools. A committee or team decides what one or two tools are best for everyone. Craftsmen may get to choose, but for several decades now, software developers have been calling themselves engineers.

I don't know much about boat builders, but I believe that mechanics are usually required to buy their own tools. As a software developer, I could write a couple of tools, choose quite a few from open source, but if I was required to purchase even one or two licenses required by my day job, I would go bankrupt.

–Doug Russell
Akron, OH

I must take exception with Rennie Allen's comments. (Mr Allen must be a very wealthy individual to absorb all that downtime between jobs as he moves around between employers who don't conform to his opinions.) On the contrary, “True S/W engineers” rarely get input into the selection of the tool set which has either been established by previous convention used at a company, a CPU/device selection that limits the choices, a clueless manager or by budgetary concerns (or a mixture of all of the above).

(Tongue firmly implanted in cheek) I am always flattered when a manager/accountant feels I can create the Queen Mary from a log using only 5 year old dental picks. It demonstrates a deep commitment by the manager for my technical ability to get things done! It also demonstrates a future failed project!

However each year in this field seems to bring with it tools which are worse than the previous year! I frequently miss my old Signum Systems 8051 bonded out ICE, I could set up “events” for breakpoints, scope trigger output, or trace start/stopping that where so complex. Such as “When this memory location has a value between these two values and this line is low, while this other line has a high going edge, and this has occurred 38 times in the past, and today is Thursday (ok, so maybe not this last part!)”, all this to develop a few K of code. But today I have projects with millions of statements and I am lucky to get a JTAG based debugger that can reliability break execution on a program counter value, is this progress???

I had hope for the Open Source Eclipse project, but it has turned out to be an excuse for semiconductor manufacturers to avoid the expense of creating tools for their new devices. As an example, I am currently working on a project that uses a Cyprus CPU with an ancient version of Eclipse (the latest that will work with this device plugin), I am lucky if I can get a single valid program counter breakpoint to work per power cycle of the board (before the debugger hangs), and forget about setting a breakpoint in an ISR function.

Static analyzers seem to be one area that is improving, but their cost is going through the roof. In one of your recent articles you “talk up” one of these products, but when I visited the website for this company, it was all about “call for quote”, and not a mention of the price for this tool. You just know it is not going to be affordable.

And that is the other side of the coin that has also changed over the years, companies developing new products no longer want to invest money in tools. I can remember projects that used Intel series 3 “blue boxes” that where $60K a piece and we had about 10 of them on the project. Nope, these days the cost per seat for a tool had better be under the low thousands or else it will never get approved.

And as for table saws, I will take my DeWalt left tilt contractor/cabinet saw hybrid over that low quality Delta Unisaw anyday!!! {lol} The DeWalt is like working with a vertical mill for wood! Now there is an industry that is making progress in its tools!

–Chris Gates
Moorpark, CA

All I can say is… it varies. I have seen pretty much everything … from those that have all of the latest and greatest tools, CASE, UML, debuggers, code generators, simulators etc… and still produce buggy results; to those that insist that printf() is the way to go … and still produce buggy results!

–Ken Wada
Sr Embedded Systems Consultant
Aurium Technologies Inc.
San Jose, CA

In 35 years, I have only seen one debugger/CPU combo that worked–SingleStep + 683xx/CF52xx. 70+% of the rest didn't have anything and the ones that tried, failed.


“That's a feature!” Yes, when C came out, this was advertised as a big feature. The problem is that neither ASCII nor mathmatical symbols in general have a 'becomes' symbol. All the various languages then have to kludge around that limitation. So Pascal has = and := , C has == and = , etc.

–William Gustafson
HW/SW Engineer
Tualatin, OR

Tools are like the ones defining development environment, CVS, test bench, etc. The quality of tools should not have a “direct” impact on the quality of the product being built. The tool should not leave any trace into the product.

Compiler and programming languages are like material. C is flexible like wood, while Ada is robust like steel. These are part of the product, and their quality has a direct impact on the quality of the end product.

–Janet Smith
Regina, SK, Canada

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.