You may redistribute this newsletter for non-commercial purposes. For commercial use contact firstname.lastname@example.org. To subscribe or unsubscribe go here or drop Jack an email.
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes.
I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia.
Jack's latest blog: How Projects Get Out of Control
Martin Keppler sent a link to a video about rebuilding an Apollo Guidance Computer.
|Quotes and Thoughts|
Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering. Fred Brooks
|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.
In the last issue I referenced an interesting article about bi-di communications over an LED by reverse biasing the LED. Siva Govindarajan wrote:
|Freebies and Discounts|
This month's giveaway is a 30 V 10 A lab power supply:
Enter via this link.
|On Honesty in Scheduling|
In the last Muse I mused about honesty in scheduling, expecting to get a lot of negative feedback along the lines of "you're just an idealist." Mostly that didn't happen. Many people complained that schedules never seems to consider unexpected interrupts. Did you know that most people are engaged in their main project only 55% of their work hours (a study in the sadly-deceased Crosstalk magazine  pegs that at 50%)? Talk to a grizzled old embedded developer about how he creates a schedule and you're likely to hear about doubling the estimate, which correlates closely with the 55/50% number.
Oh, and a schedule is an "estimate". It's never an "exact-imate". That implies a probability distribution function. Only a fool believes a distribution like this:
Here are some of the replies.
Lars Pötter wrote:
Peter Heath had an analogy:
I once met a mechanic who did everything he could not to repair my car. By that I mean he would do no repair before its time. Period.
One day after having become a bit exasperated by his reluctance to replace a fuel filter with a petrified connection that he would not fix until the filter started to cause performance issues, I asked him about this philosophy. His answer was simple and because of that it stuck with me ever since.
If I tell you something needs to be done when it doesn't, I'm lying to you. Then, I have to remember my lies. If I just tell the truth, I don't have to think about it anymore.
Needless to say, he remained my mechanic until I moved 2500mi away and could no longer reasonably have my vehicle serviced at his location any more. As I get older and my memory begins to, well, get older, his wisdom becomes all the more apparent.
BTW, I drove with that fuel filter for another 3 years and it never did give me any problems.
Harley Burton has had his battles:
Mike Davis also opts for honesty:
Bill Smithem said:
Herb Lacey has had trouble with managers:
Bob Dunlop writes from a different perspective:
VDC did a survey of the embedded space; the results came out a month ago. VDC has allowed me to quote some of the interesting statistics. As always, take the data with a grain (or a tub) of salt. In my opinion, many of the questions asked are ones engineers really don't have the data to answer. I think surveys are like impressionistic paintings; they give an interesting though vague sense of reality.
Schedules are longer than one might think. The mean is 41 months, median 12.
Mean source lines of code is 371,063, with a median of 12,500. As is typical of these surveys, the results are quoted to an absurd level of precisions (371,063?) When I ask teams how much source they work with the answer is generally accurate to +/- 50% or so. And some people will include only code written in-house, while others might fold in acquired components (Linux?).
Why are projects late? Here's the survey's results:
Total cost of engineering for the current project: Mean is $5.5 million, median $250K. I'd sure love to see the distribution on this one given the huge disparity between mean and median!
Where do those dollars go?
Processors used in current project:
To me, the most interesting results were about shipped bugs. Respondents report a (mean/median) 79/5 patches in the first year of deployment of the most current project. Cost to fix in people-hours is (mean/median) 136/24 per patch. If an engineer's loaded cost is $150k/year, that's about $2000 to $10,000 per fix. With up to 79 shipped bugs/year we're looking at hundreds of thousands to almost a megabuck in support costs due to quality problems! And that's only in the first year.
The survey is gigantic, having 6200 lines and 335 exhibits in the summary spreadsheet.
|This Week's Cool Product|
It's possible to measure temperature using nothing more than a diode as the sensor, as these devices have a temperature coefficient of about -2 mV/°C. But if accuracy is important, other options make more sense.
Maxim's new MAX30208 temperature sensor is accurate to 0.15% over 0 to 70°. Digi-Key quotes $2.23 in singles and half that in quantity.
Interestingly, the datasheet specs the power supply rejection ratio as 0.006°C/V, instead of the more common dB. I like the °C/V rating as it's so easy to interpret.
Max operating current is 100 µA, and only 1 µA in standby.
With a 2x2 mm package self-heating could be a problem, but somehow they've conquered this:
It has an I2C interface, and includes two GPIO pins.
The part is advertised for wearable devices, but I can see a lot of use for it in all sorts of sensor applications. While the IC is available today, the eval board has a six-week lead time.
Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors.
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 intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|Joke For The Week|
These jokes are archived here.
The C Programming Language -- A language which combines the flexibility of assembly language with the power of assembly language.
|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. 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 firstname.lastname@example.org for more information.