Follow @jack_ganssle

Go here to sign up for The Embedded Muse.

TEM Logo The Embedded Muse
Issue Number 272, November 3, 2014
Copyright 2014 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
   Jack Ganssle, Editor of The Embedded Muse

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

Contents
Editor's Notes

Ad

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!

I am doing public versions of this seminar in Baltimore on Nov. 7, Santa Clara Nov.14, and Germany Nov. 28. The class in Germany is full, but seats are still available in Baltimore and Santa Clara.This is a very-fast-paced full day seminar. It's fun, it's informative, and it only covers practical ideas you can use today. The seminars are quite close to airports with Southwest Airlines hubs. More information is here. I can also deliver the seminar on-site, at your facility, just to your engineers.

Salesman

Don't have time to learn how to shorten schedules? Too busy fighting bugs to master ways to reduce bug rates? Sometimes you have to stop bailing and plug the leak!

The CoderDojo folks are looking for help in getting more embedded system software developers and programmers that are not already involved in the CoderDojo movement to join the Community. As part of our efforts we have partnered with Pivot Point Research to reach potential Champions around the world. You can help us by joining the Pivotal Perspectives Program. - See more at: http://www.pivotpointresearch.com/jointhepanel

Quotes and Thoughts

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!)

Tools and Tips

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:

Lots of tools have been mentioned before, lots of good websites too. About all of them I use on a daily base. But a few (IMHO essential) websites are forgotten, or lots of programmers don't bother about it, and they are:

http://www.oxforddictionaries.com/
http://www.thesaurus.com/
https://translate.google.com

Since not everybody on this globe speaks English, or masters the language on a "Shakespearian" level, I sometimes get the creeps
reading comments, or function- or variable names. In any programming language. Writing good code includes a good spelling, and clear comments I think. If I have doubts, I check on the above mentioned sites. Since English is not my mother tongue, I want to make sure people speaking other languages still understand well and clear what the code does. But these tips include the native English speaking crowd as well. If you surf a lot on forums or blogs, you'll know what I mean.

Comments On Comments

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

The comment about "self-commenting code" by the person who claims it should be guided to read "The Art of Readable Code" by Dustin Boswell and Trevor Foucher. The book has excellent advice that relates to a number of programming languages. It even advocates the creation of the comments before you write the code (something I do for my own systems).

Daniel Wisehart wrote:

The problem with comments is that they become a second set of code, which is not checked by the compiler and is frequently ignored when the compiler code is updated. The problem becomes tremendously obvious when something stops working and the person who is maintaining the code is not the original writer or editor. The compiler code doesn't work and the comment does not match what the code does: it can take a long time to make sure you understand all of the implications well enough to delete the compiler code and the comment, create what is now needed and find the implications as they pop up.

If there was a way to track which compiler code the comment referred to, it would be a lot better. Otherwise you spend a lot of time trying to figure out if you understand how the system was supposed to work, or not.

Writing less dense code is often a better solution than writing something no one else will figure out in a reasonable amount of time and relying on the comment to carry them through.

Marketing Madness

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.

Overtime

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:

Sleepy Scale

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.

Embedded in Brazil

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.

 

Jobs!

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.

Joke For The Week

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:

Highway zero

Advertise With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

About The Embedded Muse

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. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information.