|Jack Ganssle's Blog
This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at firstname.lastname@example.org. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).
|For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.|
Thoughts on Firmware Seminars
September 12, 2018
21 years ago I sold my tools company and retired. For one day. It was boring.
Thinking back over the previous 15 years in the tool business I realized that many of the engineering teams I visited were mired in problems, in many cases problems that had been solved by others. I resolved to find ways to share this knowledge to help improve the field.
Hence, my bi-weekly Embedded Muse, which is written somewhat in collaboration with the readers. For when I write an article, many reply with great ideas that get folded into the next issue. Some readers are frequent contributors; it feels like a community of embedded engineers.
And I started teaching a one-day Better Firmware Faster class. To date over 400 companies have had me conduct this class at their facilities. In addition, I do a few "public" classes each year, where individuals from different companies attend. (Coming up: Boston and Seattle in October).
Though I teach the class, doing so has taught me a lot. Two things happen: attendees will explain a novel way they solved a problem. And in subsequent email dialog we'll explore an idea and both learn something useful. That's a ton of fun!
The engineers are almost always very bright and engaged. They toss out tough questions. They challenge my assertions. Most of the time I can convince them of the validity of my statements, because each one is backed up with hard numbers. And engineers like numbers. I don't do the "we like this approach because it's fun and the team enjoys working this way." Better: "multiple studies have shown this approach leads to a 70% reduction in bugs."
Particularly for the on-site classes, especially those taught outside of the USA, a portion of the group will invite me out afterwards for beers or dinner. An old saw states "an extraverted engineer is one who looks at your shoes when he's talking to you." Yet my experience is quite the opposite. These gatherings are generally full of laughs and stories. The folks are just a delight. Sometimes my wife is with me and they always invite her along. She is an artist, not a techie, but fondly remembers many of these evenings.
How effective is the class? Roughly a third of the groups who attend really "get it," change their processes, and gain substantial benefits. It's hard to measure this precisely, because so few groups keep any sort of metrics prior to the class, but those who do report a 30-40% reduction in schedule and about the same reduction in shipped bugs. (One of my requests at the end of each class is "Even if you decide not to implement any of these ideas, at least start collecting metrics so you can establish a baseline to measure future changes against.")
Another third implement a subset of the ideas I present. These reports are anecdotal and never metrics-based, but they tell me they're getting a substantial improvement in performance.
Another third either don't "get it," or actively resist implementing any new ideas. That's understandable; change is really hard. And in some cases the teams are wedded to their approach and are not interested in change.
Of those one-third that "get it," the bigger companies often ask me back, to a different location. In a couple of cases this meant visiting a dozen or so facilities. Sometimes those are distributed over six continents. (My friends are all retiring and are anxious to travel. When/if I retire, I'm staying home!)
And I've learned that those international trips are getting more exhausting with age. Not long ago I did a seminar in India, and a day later one in China, going completely around the world in 5 days. That's too much for this senior citizen.
Some companies ask for two and even three-day versions of the class. I've found that three days is too much for a non-hands-on seminar. Some of the aforementioned seminar companies do week-long classes, but those feature a lot of exercises for the attendees.
Another thing I've learned: charge a pretty high price for the onsite classes. Too little, and the team dismisses the ideas. Something inexpensive is perceived as having little value.
Finally, having turned 65 this summer, I've learned once again that I'm not interested in retirement. As long as health permits I plan to keep up these activities. For, this is such an interesting and fun field!
Feel free to email me with comments.
Back to Jack's blog index page.
If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."
Recent blog postings:
- Marvelous Magnetic Machines - A cool book about making motors
- Over-Reliance on GPS - It's a great system but is a single point of failure
- Spies in Our Email - Email abuse from our trusted friends
- A Canticle for Leibowitz - One of my favorite books.
- A 72123 beats per minute heart rate - Is it possible?
- Networking Did Not Start With The IoT! - Despite what the marketing folks claim
- In-Circuit Emulators - Does anyone remember ICEs?
- My GP-8E Computer - About my first (working!) computer
- Humility - On The Death of Expertise and what this means for engineering
- On Checklists - Relying on memory is a fool's errand. Effective people use checklists.
- Why Does Software Cost So Much? - An exploration of this nagging question.
- Is the Future All Linux and Raspberry Pi? - Will we stop slinging bits and diddling registers?
- Will Coronavirus Spell the End of Open Offices - How can we continue to work in these sorts of conditions?
- Problems in Ramping Up Ventilator Production - It's not as easy as some think.
- Lessons from a Failure - what we can learn when a car wash goes wrong.
- Life in the Time of Coronavirus - how are you faring?
- Superintelligence - A review of Nick Bostrom's book on AI.
- A Lack of Forethought - Y2K redux
- How Projects Get Out of Control - Think requirements churn is only for software?
- 2019's Most Important Lesson. The 737 Max disasters should teach us one lesson.
- On Retiring - It's not quite that time, but slowing down makes sense. For me.
- On Discipline - The one thing I think many teams need...
- Data Seems to Have No Value - At least, that's the way people treat it.
- Apollo 11 and Navigation - In 1969 the astronauts used a sextant. Some of us still do.
- Definitions Part 2 - More fun definitions of embedded systems terms.
- Definitions - A list of (funny) definitions of embedded systems terms.
- On Meta-Politics - Where has thoughtful discourse gone?
- Millennials and Tools - It seems that many millennials are unable to fix anything.
- Crappy Tech Journalism - The trade press is suffering from so much cost-cutting that it does a poor job of educating engineers.
- Tech and Us - I worry that our technology is more than our human nature can manage.
- On Cataracts - Cataract surgery isn't as awful as it sounds.
- Can AI Replace Firmware - A thought: instead of writing code, is the future training AIs?
- Customer non-Support - How to tick off your customers in one easy lesson.
- Learn to Code in 3 Weeks! - Firmware is not simply about coding.
- We Shoot For The Moon - a new and interesting book about the Apollo moon program.
- On Expert Witness Work - Expert work is fascinating but can be quite the hassle.
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.