You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Comments On Comments
• Marketing Madness
• Overtime
• Embedded in Brazil
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

I ran into an alumni of my Better Firmware Faster seminar while passing through San Jose airport a few weeks ago. He said his group has been able to shrink schedules by 35% while reducing bug rates by a factor of five. That the central theme of the quality movement - and this class. Fewer defects lead to shortened schedules. Are you up to speed on the best ways to produce firmware? Over 5000 other engineers are, as they have attended this class; don't get left behind!

David Albert had some comments about my observations on improving the software/firmware development process:

We had an apt saying where I used to work: "We're too busy chopping wood to sharpen the axe!"

(Abraham Lincoln would be rolling over in his grave!)

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

Steve Leibson's blog referenced an interesting paper last week about what comes after DDR4 memory. It's worth a read.

Edwin Decoene wrote:

Paul Bennett had thoughts about my comments on comments in the last issue:

Daniel Wisehart wrote:

It must be trade show season. My email in-box is overflowing with press releases announcing the latest cool new products.

Curiously, many of them read the same and use identical buzzwords. Do the PR people get paid on a per-buzzword rate? Here are some of my favorites:

Platform-driven. An example: "...and addition to its platform-driven solution..." Huh? A platform is something things rest on. "Platform-driven" is an oxymoron.

Enables, as in "This new product enables [new product name] to address the needs..." How can it be a new product if it "enables" something already extant?

Solution. For years now everything new product has been touted as a solution. I don't know about you, but my problem set still seems quite unsolved. Dictionary.com defines the word as a mixture of two or more chemicals, but it does admit to a jargon variant, very well defined as "A marketroid for something he wants to sell you without bothering you with the often dizzying distinctions between hardware, software, services, applications, file formats, companies, brand names and operating systems." And, yes, the site does define Marketroid; it's worth a look.

Disruptive technology. Cool. Just what we need, something to completely disrupt our years of work and millions of lines of code. Dictionary.com nails it again: "characterized by psychologically disorganized behavior <a confused, incoherent, and disruptive patient in the manic phase>." That's exactly the sort of tool/process/service I don't want to see in a development environment. What's next? Sociopathic technology?

Exciting new product. Most of the couple of dozen press releases that pop in here each day sport this phrase. Exciting to the marketing folks - maybe. But to most of us? Probably not. Great writers know they should never directly indicate an emotion. "He was sad," might be accurate but isn't compelling. Better: "tears ran down his cheeks as he choked a few last words to his dying wife." Don't tell me a product is exciting; paint a picture that gets my heart beating faster. If that's impossible, the thing is probably rather banal.

Missing piece of the solution. How could it have been a solution if there was a piece missing? Maybe the technology was so disruptive its "psychologically disorganized behavior" left the users so bewildered they were getting nothing done anyway.

"[Company name] is private so doesn't release sales figures, but has experienced strong growth." So if they sold a dollar's worth of products last year and $5 now, that's a startling 500% growth. WOW! I give them a strong buy rating as they'll surely be the next Google.

Framework. See "platform."

The use of undefined acronyms. A single press release included all of the following: SCARI, JTRS, ORB, SCA, ATCA, and VON.

[Company name] is the global leader in [some technology.] Synonyms: "market leader," "industry's premier," "best in-class solution," etc. Today I received two press releases about the same sort of product from two companies, each of which claimed to be the global leader. These baseless claims don't impress quantitative engineers.

Then there are the quotes from company executives. "This is the most advanced total [something] solution of it's [sic] kind on the market today, with the highest ROI to our customers." Give us substantiated facts, not inflated marketing-hype. These sorts of quotes add nothing to the press release. None of us will buy a product because the vendor's CEO thinks it's nice.

Then there's the usual concluding sentence: "available now." Uh huh. Sure. The sad part is that this phrase is so overused that none of us believe it anymore, even though once in a great while it's true.

Tired people make mistakes.

That's a thesis of many agile methods, and is just common sense. Yet all too often we're required to put in crazy hours to get a project out the door. I have stacks of examples of software disasters caused at least in part from months of 60 to 80 hour weeks

Proponents of eXtreme Programming recognize that overtime is inevitable but that tired people make mistakes. So their rule is that we can't work overtime two weeks in a row.

That may be bad advice. The US Army has concluded that going on less than six hours of sleep a night for six nights in a row results in a 20% cognitive impairment. That's the same as having a 0.08 blood alcohol level. 0.08 is considered "drunk" if driving.

Does your company encourage developers to work effectively plastered?

In a 2003 study ("The Cumulative Cost of Additional Wakefulness: Dose-Response Effects on Neurobehavioral Functions and Sleep Physiology From Chronic Sleep Restriction and Total Sleep Deprivation") in the journal "Sleep" (no kidding; there really is such a publication), the authors studied sleep deprivation on subjects over a two week period. One of the metrics used measured the number of correct number of solutions per minute to some arithmetical problems, which is probably analogous to working on firmware. The results:

Top curve: 8 hours sleep/night. Next lower: 6 hours. Next lower: 4 hours. Bottom curve: 0 hours.

Eyeballing the curve suggests these results match the Army's concern that six hours sleep for six nights results in a 20% cognitive decline. It's interesting that on four hours/night no correct answers result, starting pretty much from day one.

Plenty of studies show that after six to eight hours a knowledge worker's productivity drops considerably. Overtime can actually negatively impact a project since error rates go up. In firmware, the biggest source of schedule slippages is bugs (Capers Jones, Assessment and Control of Software Risks). Work too many hours and the deadline will disappear over the horizon.

There's quite a lot of embedded work in Brazil, and for a few years the Brazilian Embedded Systems Conference has been quite successful. A new survey of the market there has just been released, and some of the data is quite interesting. The survey is here. Unfortunately, you must register to get to the data.

A few highlights:

• 75% of developers there are under 40 years old. 47% are under 26. That mirrors my observations from travels there. We engineers in the USA and Europe are aging, but in developing nations a lot of young people are getting into this field.

• Only 25% have more than 10 years experience. Compare that to an average of over 20 years in the USA.

• 71% report working in C; 15% in C++. Worldwide a bit over 60% of firmware people report using C and around 25% C++.

• Only 13% of operating systems in Brazilian embedded systems are commercial. The rest are open source or developed in-house. Linux gets the lion share; the most popular RTOS is FreeRTOS.

• Subversion and Git have 68% of the version control space there. Fully 36% report no use of a VCS. That's not much different from the rest of the world.

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.

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

Driving through Missouri recently I discovered that some highway engineers count from zero, like computer people:

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