Embedded Muse 195 Copyright 2010 TGG May 3, 2010

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

Editor's Notes

Are you happy with your bug rates? If not, what are you doing about it? Are you asked to do more with less? Deliver faster, with more features? What action are you taking to achieve those goals?

In fact 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 http://www.ganssle.com/onsite.htm .

Quotes and Thoughts

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. Edsger Dijkstra (Whilst not avoiding clich‚s? - Jack)

The Resume Follies

After a long hiatus it seems companies are hiring again. Candidates are polishing their resumes, cranking out cover letters, and polishing their shoes for interviews. I worked with an analog designer for many years, one whose skills were adequate but less than stellar. A nice guy, though, he became a close friend during the battles of getting products to market. One day I asked about his background; turns out all of his education was in the digital arena, his analog expertise limited to that learned in college.

"How did you get this job?", I asked, somewhat aghast.

"I needed work, and this looked like a good opportunity. Don't tell the boss, but I just tuned my resume to meet the skills requested in the advertisement."

Decades have passed since then, and I've often wondered where our ethical boundaries lie in creating a resume. Moralists might claim that absolute unrelenting honesty is the only policy in any ethical quandary. I have doubts. My late grandfather was a tough old salt, a tugboat captain whose unedited honesty made my grandmother's existence a living hell. Never would a banal kindness pass his lips unless provably correct. Even a "you look nice today, honey", the sometimes not-quite-true social grease necessary in all relationships, was, to him, an unacceptable violation of the ninth commandment.

Parents practice a bit of truth management when they praise the young child's random crayon slashes, comparing these to great art. We help budding drivers gain experience and confidence by complementing the newbie on a rough start in first gear. because it's not quite the gear-crunching whiplash start of just a few days earlier. When the big boss pushes for C++ on an 8051, a wise employee will cite the dearth of compilers rather than publicly explore the depths of the boss's ignorance.

So where's the line on resumes? How honest should they be? The oldest trick in the book is editing by omission. It's self-destructive to note that you were fired from that job; better wait and see if questioning during the interview drags up that unhappy event. A short stint from 6/99 to 8/99 might look a bit better if described as "1999". And it's probably a good idea to leave off the detailed description of that stint in the mental ward (which one resume I had the dubious pleasure of reading described at length).

Wholesale fabrication of experience, though, strikes me as being unacceptably dishonest. Though companies are getting quite aggressive in looking for felony convictions, debt problems, manufactured diplomas, and much else, it's still rather hard to prove that Joe Coder never actually did write the Linux TCP/IP stack. Careful questioning at the interview may reveal the deception, but a surprising amount of experience listed on any resume goes unchallenged.

What do you think? What resume-polishing advice would you give to a developer who has experience shortfalls or employment gaps? How much truth management is ethical?

Superprogrammers

An old (April 1, 2003) issue CIO Insight has an interesting opinion piece by John Parkinson. Parkinson has collected years of productivity data that shows 75 percent of his company's delivered code came from just 5 percent of the programmers. 100% of the best code - that having the fewest defects - came from the same highly-effective developers.

This isn't new news; the legend of the superprogrammer is almost as old as the computer itself. In my career I've worked with developers of all stripes and capabilities, from total losers who survived just a short time on the job to a few that surely deserved the superprogrammer moniker.

DeMarco and Lister showed that teams can act like superprogrammers; their classic book Peopleware (a must-read) demonstrated that simply taming interruptions can triple developer productivity.

Parkinson admits he later lost sight of the superprogrammer elite as he found it easier to use tools and processes to improve the average programmer's productivity a bit, than to chase down the rare and elusive miracle worker. Further, these folks tend not to stick around for along time, making it even harder to build a functional organization around them.

I wonder, though, if Parkinson's loss of the superprogrammer stems more from the changing nature of products than from an inability to recruit and hang on to these folks. His data comes from projects built 20 years ago when software was small. Times have changed; projects today are huge, often comprising millions of lines of code. Old timers remember when the PC's 640k RAM limit seemed infinite.

Caper Jones, in an unpublished 1977 study for IBM, found that the very best developers are much more productive than the worst programmer. when working on small projects. The best developer will complete a 1k line of code (LOC) effort 6 times faster than the lousiest. The productivity delta falls to 2x on a 64k LOC project. Beyond a few hundred thousand LOC both sorts of people perform equally well. Or equally poorly.

Jones' data meshes with common sense. A single person can completely build a small project. The superprogrammer employs his or her arcane art and techniques in a blitzkrieg development effort that requires no interaction with lesser peers. As projects grow in size, more people are needed, memos, meetings and mail eat into the work day, and the personal interaction eschewed by so many of the best developers becomes as important as raw programming ability.

So superprogrammers aren't all that valuable, unless one is wise enough to use them exclusively on small jobs. That never happens. In my travels I see a universal pattern that puts the best people on the toughest - read biggest - projects. Neglecting Caper Jones' data and the evidence of their own disastrous development efforts managers thus manage to make everybody equally ineffective.

But one thing is certain - most of us consider ourselves either superprogrammers or well above the mean. I'm told surgeons have egos that fill an operating theater. Trial lawyers, too, seem to have an astonishingly inflated sense of self. Engineers fit the same mold. We're driven in large part by our desire to solve problems, and our sure knowledge that we're smart enough to do so. I bet that most of us rate ourselves way above average.

Tools and Tips

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.

Embedded Software Engineer - Absolute Software Ltd, Cornwall, England. Absolute Software is a fast-growing embedded software development company based in the most beautiful corner of England. We are proud of our unique design process combining Agile, Embedded and Quality Assurance creating a productive but relaxed working environment. Experience with low level drivers, Microchip PICs, ARMs, C and C++, are all of benefit. Email CVs to recruitment@absolute-software.co.uk.

My company in Huntingdon Valley PA wants to hire a junior programmer 2 - 7 years experience for projects that could involve mesh networks on small low power processors or embedded TCPIP on ARM9 using Micrium. Send resumes to me at Erick@sapling-inc.com

InHand Electronics in Rockville, MD is an original equipment manufacturer (OEM) of mobile single-board computers. InHand is seeking experienced software developers who have a strong background in operating systems and device drivers. Kernel-level experience with at least one of the following operating systems is required: Windows Embedded Standard, Android, Windows CE 6.0, or Linux 2.6 (any distribution). Experience with multiple operating systems is a definite advantage. For more information: http://www.inhand.com/company/careers

Master's degree in EE/CS or Bachelor's degree with suitable experience.

Submit your resume, with cover letter, to: jobs-usa@lantiq.com

Endress + Hauser's located in Greenwood, Indiana is seeking a full-time software engineer for a measurement device for the process industry with a large embedded SW content. The engineer will participate in the design, implementation and testing of embedded software. The small team of 3 to 4 engineers works jointly with Endress + Hausers larger software group, located in Germany.

The team works according to the lean principles of agile software development designs and implements embedded code and test software with C++ and C# according to safety standards including static tests, unit tests and system tests.

The Embedded Software Engineer should have experience in embedded SW design and tests, SW test methods like unit level testing, integration testing, working knowledge of C# and C++, knowledge of UML language for formal design methods for embedded software, basic understanding of controller hardware, working experience in agile software teams.

In addition, the selected candidate for this position must be able to experience limited travel to Germany for training, including four weeks for start up, and approximately one to four weeks per year for start up of project iterations

Please file your application to humanresources.lp@us.endress.com

Joke for the Week

From Edward Gibbins:
I was on a trip for work the other day and got a bit lost....
I went past one building marked 128k, another marked 256k, one 512k and
the building at the end of the road was marked 1Mb. Then I realised I
had taken a trip down memory lane!

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

Do you need to eliminate bugs in your firmware? Shorten schedules? My one-day Better Firmware Faster seminar will teach your team how to operate at a world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and covers the unique issues faced by embedded developers. Here's information about how this class, taught at your facility, will measurably improve your team's effectiveness.