From: owner-embedded@ganssle.com on behalf of Jack Ganssle [jack@ganssle.com] Sent: Monday, January 03, 2005 8:28 AM To: embedded@ganssle.com Subject: The Embedded Muse 108 The Embedded Muse -------------------------------------------------------------- Embedded Muse 108 Copyright 2005 TGG January 3, 2004 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. 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 -------------- There are no current plans to host a public Better Firmware Faster seminar, but I often do this seminar on-site, for companies with a dozen or more embedded folks who'd like to learn more efficient ways to build firmware. See http://www.ganssle.com/onsite.htm. 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 ---------------- Thanks to Slashdot I've run across a couple of interesting computer history web sites recently. It seems someone with too much time on his hands created a replica (using the word loosely) of the Apollo Guidance Computer used on the moon missions. See http://klabs.org/history/build_agc/ . Doctor Dobb's (http://www.ddj.com/documents/s=1494/ddj0006hc/ ) has a quite fascinating description of the machine. Another great history site with good links is http://www-106.ibm.com/developerworks/library/pa-microhist.html?ca=dgr-lnxw01MicroHistory . Recommended. Salary Survey ------------- Thanks to the more than 1200 people who responded to the salary survey. I've tabulated the results - a much bigger project than expected, but simplified by writing a pile of code to reduce the data. The results are interesting. 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 http://www.ganssle.com/salsurv2004.pdf . More on Testing --------------- A couple of people had some interesting thoughts on my testing comments in the last Muse. Christian A. Schreiner wrote: A number of the Deming books I have read emphasize that testing is very necessary for processes that one can't control well enough to eliminate defects in advance. He even noted that electronic products tend to need thorough testing. He does emphasize, though, that this doesn't mean that testing can make up for bad (or no) designs, uncontrolled manufacturing, or misunderstanding how the product will be used. 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! ----- Let me know if you're hiring firmware or embedded designers. I'll continue to run notices for embedded developers as long as the job situation stays in the dumper. No recruiters please. There are no listings this week. Joke for the Week ----------------- For the first bug of Christmas, my manager said to me See if they can do it again. 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. About The Embedded Muse ----------------------- The Embedded Muse is an occasional newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com. To subscribe, send a message to majordomo@ganssle.com, with the words "subscribe embedded email-address" in the body. To unsubscribe, change the message to "unsubscribe embedded email-address". BUT - please use YOUR email address in place of "email-address". 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.