You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Is it a Bug or an Error?
• More on SPARK and Ada
• On Engineering
• No Degree? No Problem
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Wouldn't you want to be in the top tier of developers? That is part of 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 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.

I'll be wandering the halls of Embedded World (Feb 27 to Mar 1); feel free to stop me and chat.

Andrzej Telszewski sent this quote: "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery

Here's a site full of all sorts of calculators.

Long ago we were taught to match input resistors on an op-amp. Turns out, that advice might be as antiquated as a 741. Interesting article here.

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

In Muse 340 I included a quote from E. W. Dijkstra where he suggested we abandon the word "bug" in favor of "error." Readers had a range of opinions, but it did spawn a discussion among a small email group of people who write about embedded systems.

Mike Barr's posting on the subject is here. Chris Hills take is here. Jacob Beningo posted this.

Here's my take:

I've never had a bug in my code.

I wrote my first computer program 49 years ago. This was via a time-sharing service at a friend's high school using a Model ASR-33 teletypewriter, connected to a remote Honeywell mainframe over a 110-baud modem. Storage was paper tape.

At the time I was making minimum wage, $1.60/hour, but computer time cost $4/hour, so instead of a practice "hello world" bit of code, it was a FORTRAN simulation of an AI robot. It didn't work at first, but eventually I removed my mistakes and got the results I'd hoped for.

In the succeeding half century and thousands of programs I have never had a bug in my code. Not one.

Admittedly, I've made lots of mistakes. Errors. Goof ups. Brain-dead dumb stuff. Code that was so flawed one wonders what I was thinking. Or subtle mistakes that consumed weeks of troubleshooting.

In some cases the problems stemmed from uncontrollable events, like chips that didn't function as the datasheets claimed. But most were self-induced errors I injected through my own blunders.

"Bug" implies that something bad snuck into the code when I wasn't looking. I left the window open, went to get a cup of coffee, and of its own volition that nasty bug slipped into the code.

Really?

When I ran the Dijkstra quote advocating for the term "error" over "bug" a few readers were outraged. One wrote that he has dyslexia and he relies on his compiler to find those sorts of bugs. I don't know much about that affliction so can't comment. In the spirited email discussion mentioned above, one of the participants note that he, too, has dyslexia.

Other readers thought "bug" insulated them from the boss's ire. "If we call these errors," one reader opined, "then the boss will be all over us. 'Error' makes us accountable."

Exactly.

Practicing engineers call these goof-ups "bugs." In the literature they're referred to as "defects," a better term as that encompasses everything from outright mistakes that cause the system to malfunction to minor spelling or documentation problems.

I think Dijkstra is correct, and we need a better moniker that holds us more accountable than "bug." It could be "error," or even "damn-fool screwup," but let us be honest: the blame lies with we who write the code. "I made that mistake" is much more honest than "uh, this code seems to be buggy." (Admittedly, there's often plenty of blame to go around, like when we're given incorrect requirements).

Section 1.3 of the ACM Code of Ethics requires us to "Be honest and trustworthy." The IEEE Code of Ethics is even better, in part commanding us "to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors."

Those are excellent aspirational philosophies to guide our work.

Aspirational, because we will always make mistakes. Debugging, uh, de-erroring, is simply a fact of life in this business. But let's own up to the source of the errors. Once we own the problem, we can start looking for solutions... or at least ways to drastically reduce our defect rate.

Sound impossible? The SPARK community doesn't think so. Their motto is "Correctness by Construction." Sure, SPARK users, like the rest of us, make mistakes, but their tools and processes ensure that these rarely make it into the code (even in initial testing an extremely low, or even zero, defect rate occurs). The late Peter Amey wrote "In my 10-plus years of using SPARK, I have never needed to use a debuggger. I have become so used to things working the first time that my debugging skills have almost completely atrophied." (The next article in this Muse has links about this).

Most of us can't, or won't, use SPARK or other languages that are less error-prone than C. But the literature is full of ways to reduce our defect rate regardless of language.

Did you know the average developer injects 5 to 10 errors per 100 lines of code, and removes only 85% of these before shipping? High quality teams make only half to a third as many mistakes and remove 96% during de-erroring. Best-in-class safety-critical groups do even better.

Oh, but the cost of getting it right! Turns out, teams working with languages like C and C++ can get great code for no incremental cost if they improve their processes (Safety Critical Software and Development Productivity by O. Benediktsson).

The trick is for us to own up to our inevitable errors, and to work harder and smarter to avoid them.

Riffing on an AA theme, perhaps we should stand up and say "Hi, I'm a firmware developer and I make mistakes."

Nick P sent links to some presentations and studies about the efficacy of the Ada and SPARK languages:

In the last issue I claimed engineering is about:

• Predict what is going to happen.
• Make it happen.
• Measure to see if it really happened the way you expected.

Harold Kraus had a more complete view:

Michael Linden came across something surprising recently:

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 intent 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.

There are only two really difficult things in programming:

- Naming
- Cache invalidation
- Off-by-one errors

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