Go here to sign up for The Embedded Muse.

Embedded Muse 217 Copyright 2011 TGG December 5, 2011

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

Editor's Notes

Lower your bug rates. And get the product out faster.

Sounds too good to be true, but that's the essence of the quality movement of the last few decades. Alas, the firmware community didn't get the memo, and by and large we're still like Detroit in the 1960s.

It IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm .

Quotes and Thoughts

"Inside every large program there is a small one trying to get out." - Tony Hoare

Tools and Tips

Quite a few people have asked for input on the inexpensive oscilloscopes and logic analyzers that are typically connected to a PC via USB. I wrote a review (https://www.ganssle.com/microscopes.htm) of some, but that was back in 2005. Since then quite a few new and revised products have come to market. Does anyone have any information to share on these?

Links

This is an very creative and funny technology comic: http://ohmart.org/ .

Origin of the Word "Geek"

According to a recent opinion piece in the latest CrossTalk magazine (http://www.crosstalkonline.org/storage/issue-archives/2011/201111/201111-0-Issue.pdf), the word "geek" has an etymology that's not what one would expect:

"The word itself stems from early English and German dialects where it meant "fool." The root still survives in Dutch and German dialects today. The more Western European and eventual American definition was originally used to describe circus performers who performed disgusting acts and side show novelties like biting the head off a chicken."

Refactoring

"An architect's most useful tools are an eraser at the drafting board, and a wrecking bar at the site." - Frank Lloyd Wright.

eXtreme Programming (XP) (http://www.extremeprogramming.org/) advocates a similar philosophy: refactor relentlessly. If the code can be improved, it must be improved. Ugliness is unacceptable. Elegance uber alles.

Unfortunately, the definition of refactoring has been obscured by hearsay and casual use by folks who haven't read the original papers (for a good treatise see the c2 Wiki at http://c2.com/cgi/wiki?WhatIsRefactoring). Some use it to mean iterative evolution: changing the code to add new functions. Others see it as bug-fixing. Neither is accurate.

Refactoring is simplifying the code without changing its behavior. Its purpose isn't to add functionality or fix bugs; rather, we refactor to improve the understandability (and hence maintainability) and/or structure of the code.

XPers make the interesting point that code duplication is one clear indication refactoring is needed. I go a bit further, arguing that wise developers count bugs and recode functions that have high error rates. That might involve refactoring (usually an incremental approach) or tossing bad routines and recoding from scratch.

Refactoring is not a new concept. In his 1981 book "Software Engineering Economics" Barry Boehm showed that a little bit of the code is responsible for most of the problems. He demonstrated that a lousy routine eats 4 times more development effort than any other function. When we're afraid to modify even a comment, when the slightest change breaks a function, when the thought of any edit gives us the sweats, that's a clear indication the code is no good and should be rewritten. The goal isn't to add features or fix bugs; it's to make the function maintainable.

The alternative is to try and beat cruddy code into submission, a never ending battle as the each "improvement" leaves the software an even more convoluted mess.

The boss will freak if he hears you're tossing or restructuring working code. An old IBM story is illustrative: an engineer made a million dollar mistake, back when a million dollars was a lot of money. He was summoned to the office of President Tom Watson. Quaking in fear the engineer blurted: "I guess you'll be asking for my resignation." "Resignation," replied Watson incredulously, "I just put a million dollars into your education!"

Making a mess of a function is also an important educational experience. We may have screwed up, but have learned a lot about what should have been done. Use the experience we've just gained and refactor the mess.

The Dumbest Thing I Did

When interviewing I always ask candidates (those with experience) about their dumbest mistake and what they learned from it. Those with no mistakes are generally those with no experience - or are perhaps truthiness-challenged. Do you have any?

John Hardesty had this admission: "I worked as a temp for someone who had his own personalized technique for keeping the development directory clear of all those nasty temp files like listings, map files, etc. He would mark real files (source) as Write Protected and do a DEL *.* when he wanted to clean the directory of the trash. I was working late one night and tried to make an edit to one of those pesky source files. Several times I changed the protection, made the modification and put the protection back where it was. I finally got tired of doing that and just removed the Write Protection from everything. I had intended to do this while editing and then put it back. Unfortunately, it took until the wee hours of the morning to get everything debugged and tested. I left a note about what I had done and asked him to do one last test before checking in the source. Alas, I forgot to reinstate the Write Protection before going home for the night. We already know what happened the next morning when he came in and tried to clean out the trash before doing a release. I.E. DEL *.* Two lessons were learned. He learned not to use that technique (I wrote a batch file to get rid of the specific files). I learned not to let the boss do stupid things without at least warning him."

Stewart Pugh wrote: "We were debugging the 13 kv high voltage plate supply for a medical cyclotron. I needed an ohm meter. The best one for the job was kept in the locked desk drawer of the chemist. With a soldering iron the chemist had carved into the plastic body of the meter the usual threats of violence and dismemberment if this meter left her desk. So of course I borrowed it with out permission, she will never know. The expected explosions happened when the power was turned on and we forgot the connected meter. Don't know what was more dramatic, the exploding meter or the chemist's vengeance.

Dave Comer confessed: "When taping out a 26% shrink of the 8051 in late 1980's for Signetics (formerly Philips and now NXP) I overlooked the final of 32k error messages from the design verification tool, "Dracula". Had I read the error message I would have seen that a piece of polysilicon was detected as missing from the schematic to layout compare. This rendered the T2L to T2H high carry bit useless. You see, when validating the 8051 the practice was to exclude the ROM and RAM array cells from the verification. Hence 32k errors were expected. This was an acceptable trade-off due to the long verification execution times and the cells never changed once verified. I was unaware, however, that the layout manager had worked late the night before "cleaning up" the design. Hence 32k errors were expected. The last 32k + 1 error was due to the layout managers "clean up". I of course "took the bullet" for my co-workers' deed as I was responsible for the final verification. I later found out that the layout manager knew that he had done this long before the parts were out of FAB."

Jobs!

Let me know if you're hiring firmware or embedded designers. 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.

No jobs this week.

Joke for the Week

Note: These jokes are archived at www.ganssle.com/jokes.htm.

Richard Miu sent this one:

The one test every embedded system must pass is the dreaded ground hog test. To perform this test, take your first prototype unit into the lab and connect it to a de-energized power supply. Then stand back, look the other direction and throw the switch. If you see your shadow, there will be 6 more weeks of development.

About The Embedded Muse

The Embedded Muse is a newsletter sent via email by Jack Ganssle. 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. can take now to improve firmware quality and decrease development time.