You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
Happy New Year to the Muse community. I wish you and yours a great 2016. May all your code be bugless!
Give your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. This is what my one-day Better Firmware Faster seminar is all about. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.
An excellent short pair of articles (article 1 and article 2) from QSM discusses an analysis of 1060 software projects. The author shows that small teams consistently deliver better code for much less money than large teams. And while the bigger groups get to market faster, the difference is only a handful of percent.
I'm now on Twitter.
|Quotes and Thoughts
"A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering." - Freeman Dyson (Alas, I have met more than a few prima donnas in this field - Jack).
|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.
Margaret Johnson wrote:
Luca Matteini had some thoughts about PCB layout software:
|Freebies and Discounts
Steve Morse is the lucky winner of last month's contest; he got a LogicPort logic analyzer..
This month I'm giving away a copy of Gary Stringham's excellent Hardware/Firmware Interface Design.
The contest will close at the end of January, 2016. It's just a matter of filling out your email address. As always, that will be used only for the giveaway, and nothing else. Enter via this link.
|Careful Hardware Design
Tim Wescott has some thoughts about careful hardware design:
Accepted wisdom is that most of the cost of software lies in its maintenance. As far back as the 70s various researches pegged it at 40-80% of the total lifecycle cost, with most of the papers leaning towards the higher numbers.
Nothing seems to have changed; Bertrand Meyer (in Objected Oriented Software Construction) claimed that in 1997 70% of software costs belong in the maintenance phase.
But is this true for firmware?
To my knowledge there are no studies on the subject; indeed, embedded systems are the stealth segment of software which simply doesn't garner the research applied to IT projects. So all we can do is speculate. But if that astonishing 70% number did apply to our projects, the cost implications are staggering.
Embedded code is inherently different than that living in the world of a PC. Despite 'net-based reflashing that some products support, for most firmware a software upgrade is very costly. The car must come back to the dealer, or an instrument has to be returned to a repair depot. One could argue that these costs change the nature of the code; that the expense of doing an upgrade is such that firmware engineers inherently build better code. And, of course, some products are never upgraded, like a smart toothbrush.
Meyer quotes a study by Lientz and Swanson finds that 42% of maintenance costs stem from changes in user requirements. My sense is that there's little of that in the embedded space. MP3 players neither get recalled for bug fixes, nor are a stream of continuing software releases that improve functionality available. Instead, vendors launch a new version of the product, one that has a raft of newer, cooler features. The previous version's hardware and software is obsoleted.
That's very different than the PC, where on might use versions Word for years, contributing to Microsoft's bottom line via a never-ending series of upgrades rather than replacements.
Perhaps in the embedded world maintenance due to changing requirements is really expensed as new product development.
Lientz and Swanson claim 18% of maintenance costs come from changes in data formats. That smells like a problem in the info-processing world than in firmware. 21% are due to bug fixes, a plague shared by all programmers, and 6% from hardware changes. One would think that is entirely in the embedded domain.
But maybe things are changing. Philips recently sent a patch to their smart light bulbs that disabled access to competitors' products. (Yes, for a mere $60 each you, too, can outfit your house with bulbs that some teenager can hack). The company backed down after being deluged with complaints. We've all heard about the cheating software VW will have to patch.
Is the future of firmware maintenance cleaning up ethical lapses?
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. There is no charge for a job ad.
|Joke For The Week
Note: These jokes are archived at www.ganssle.com/jokes.htm.
From RISKs Digest 28.91: "A great example appeared in a 1999 issue of Computing. A representative of a company with a voice recognition product prepared to demonstrate their product and asked the crowd gathered to see the demonstration to be quiet. Someone in the back of the room shouted, ``Format C Colon Return!'' Someone else shouted, ``Yes, Return!'' The software worked perfectly, reformatting the primary disk on the demonstration unit, requiring that the machine finish its format and have all of its software and data reinstalled."
|Advertise With Us
Advertise in The Embedded Muse! Over 25,000 embedded developers get this twice-monthly publication. .
|About The Embedded Muse
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at email@example.com.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.