Embedded Muse 108 Copyright 2005 TGG January 3, 2005

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Salary Survey
- Computer History
- More on Testing
- Jobs
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

My apologies. The picture in the last Muse is a fraud, a Photoshopped picture of a nuclear submarine’s control panel. I was taken in by one of those Internet hoaxes. Many – and I mean MANY – of you wrote in with the snopes link (http://www.snopes.com/inboxer/hoaxes/computer.asp ). Now we know what those two concentric wheels are for.

Dan Nordell wrote (with what I hope isn’t yet another urban legend!) that the man posed in the faux picture is Joss Ackland, a British actor that Hollywood often casts as a Russian politburo member. In the movie K19 he plays Marshal Zelentsov. He played Ambassador Andrei Lysenko in the movie “Hunt for Red October”. What is most interesting – and perhaps whoever made up the hoax was purposely playing tricks on us – is that both K19 and Hunt for Red October are movies about nuclear submarines.

Computer History

Another great history site with good links is http://www-106.ibm.com/developerworks/library/pa-microhist.html?ca=dgr-lnxw01MicroHistory . Recommended.

Salary Survey

Average salaries, not surprisingly, vary quite a lot by region:

Australia/New Zealand 49644
Brazil 20333
Canada 63337
Eastern Europe 11914
India 15725
Mexico 13000
Pakistan 6000
Philippines 6800
Singapore 33540
South Africa 44942
United Arab Emirates 7000
USA 80383
Western Europe 59927

One consultant reported 2004’s income at $1m, saying he’d had a really good year. I left that data point out of the mix as it skewed the results. But what a job!

Developers are mostly young, averaging 37.5 years old worldwide with a standard deviation of 8.8 years. But in the USA we’re older, 39.5. Respondents in Western Europe reported ages up to 54, and in the USA up to the late 60s. No where else in the world did anyone respond with an age over 49.

There’s lots more data, far too much to pack into this newsletter, at https://www.ganssle.com/salsurv2004.pdf .

More on Testing

I also find it interesting that most of the quality rhetoric we run into (including most of Deming's writings) focuses on the _manufacturing_ process-- "Once we've designed a new car, how to we make 1,000,000 of them with high quality in each?" For embedded software, the manufactuing process is almost trivially simple-- you duplicate CD's or download firmware over the internet. You have to read closer to find Deming's quality-by-design writings, which teach engineers (and software developers) how to design products that don't break easily. Amazingly enough, a lot of what he says sounds like a mechanical-engineering-oriented variant of having design reviews, having a well planned architecture, having well understood requirements, and all the other things the Muse preaches.

A slogan I've often used in the workplace is, "We want the software to work by design, not by luck." I find it appalling that heavy equipment manufacturers like Cat and Deere require a new axle on a bulldozer to spend a full _year_ (that's 24x7) in a giant machine that jiggles and twists it in every conceivable way, yet expect a few afternoons of poking a few convenient values into memory to suffice for software testing!

Glenn Dixon wrote: I received your Embedded Muse with your rant on testing, and appreciate your insights. One comment on the Deming quote you used, that said you 'can't test in quality.'

Of course you can. I have great respect for Deming, but he was wrong (or better, misinterpreted) on this one. Bob Pease points out that testing is one way the semiconductor industry, which can have IC yields as low as 50% off a wafer, guarantees their exceptional out-of-the-door quality. Even in Deming's world testing is an essential part of the quality mechanism as part of the data collection necessary to keep the process in control.

I think Deming meant testing cannot change the product being tested (sorry, Heisenberg)--if the product was bad to begin with it will still be bad after it is tested. But he, likely more than anyone, advocated testing as an essential part of the quality mechanism. The very existence of his data shows that.

Deming's quote is famous enough that it qualifies as one of the 'things managers use to do stupid things'--in this case to justify spending less money on testing (I wonder how many times NASA managers have used it?). Another is that weird HP study (now myth) that still pops up occasionally, which says 'money doesn't motivate engineers.'

Software development is different from hardware manufacturing as well--here testing comes very close to actually being able to change the product itself if the developer is in a tight test-and-correct loop.

Jobs!

Joke for the Week

For the second bug of Christmas, my manager said to me
Ask them how they did it and
See if they can do it again.

For the third bug of Christmas, my manager said to me
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the fourth bug of Christmas, my manager said to me
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the fifth bug of Christmas, my manager said to me
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the sixth bug of Christmas, my manager said to me
Reinstall the software
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the seventh bug of Christmas, my manager said to me
Say they need an upgrade
Reinstall the software
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the eighth bug of Christmas, my manager said to me
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the ninth bug of Christmas, my manager said to me
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the tenth bug of Christmas, my manager said to me
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the eleventh bug of Christmas, my manager said to me
Say it's not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.

For the twelfth bug of Christmas, my manager said to me
Tell them it's a feature
Say it's not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump...
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.