How to Develop Better Firmware Faster
A one-day course for people who must develop high-quality embedded firmware on ever-shorter schedules - presented at YOUR company's facility. Brochure here.
Best in class teams deliver embedded products with fewer than 0.1 bugs per thousand lines of code. They consistently beat the schedule, without grueling overtime.
Does that sound like your team? If not, what action are you taking to improve your team's results? Hoping for things to get better won't change anything. "Trying harder" never works (as Harry Roberts proved in Quality Is Personal).
Unfortunately few firmware groups keep metrics, but those that do average a 40% decrease in schedule and an order of magnitude improvement in bug rates after implementing the ideas from Jack's Better Firmware Faster class.
Table of contents for this page:
- Seminar Summary
- Seminar Outline
- Comments From Attendees
- Why You Should Take This Seminar
- A Few of The Companies That Have Had This Class In-House
This one-day course will teach you practical - and proven - ways to develop better firmware faster. It's for the developer who is honestly looking for new ideas, but who wants to cut through the academic fluff of formal methodologies and find better ways to work now.
The focus is uniquely on embedded systems. You'll learn new ways to link the hardware and software, to stamp out bugs, to manage real-time constraints, to meet impossible deadlines and much, much more.
The course is targeted to developers engaged in creating products now who must find ways to work more efficiently.
Two of the themes that run throughout this class are:
- Improving the code's quality will shorten the schedule. This is the central idea behind the quality movement which revolutionized manufacturing. Better code, faster.
- Software engineering has a lot of fads. In this class you'll learn about measurably better ways to build systems, because, after all, engineering is about measuring things. All material will be presented with real-world numbers.
- Will code reuse benefit us? How to make a decision quantitatively.
- How to create an accurate schedule.
- And, how to manage a schedule to meet the very real needs of the boss.
- How to infuse the entire development effort with a quality focus.
- The best way to manage feature creep.
- Overcoming the biggest productivity busters.
- Managing bugs to deliver world-class code... fast.
- Quick code inspections that keep the schedule on-track.
- Cool ways to find hardware/software glitches.
- The art of designing predictable real-time code.
- And the worst gotchas in real-time systems, and how to avoid them
- Preventing system performance debacles.
- Finding - and preventing - those hard-to-reproduce erratic crashes.
- Understanding how high-speed signals affect firmware development.
- What we can learn from specific embedded disasters.
- A seven step plan to firmware success.
Each attendee will be awarded 0.7 Continuing Education Units.
The green bugs were caught using a proactive debugging approach described in the course; the blue bugs were fixed much more expensively using traditional techniques.
Your training has made a big impact in our work and our team is far more disciplined and productive than ever before. We just got back from a trade show where we showed a product we applied your insights toward, and 1) there were no embarrassing failures like previous years, 2) every feature delivered was finished and debugged instead of half working, and 3) customer response was typically "Where has this product been all my life???" Brad Nelson, Skip-Line, Inc.
Thanks so much for your time and for the great seminar. I took more away from it than I could have imagined. Adam Roman
Damn you were good, and I talk for all the boys. I think that I have been to around 100 seminars the last couple of years, and I have bored myself to death every single time, but this one was great, I'm amazed how good and fun it was. Soeren Panduro, APC
Thanks for a valuable, pragmatic, and informative lesson in embedded systems design. All the attendees thought it was well worth their time. Craig DeFilippo, Pitney Bowes
I just wanted to thank you again for the great class last week. With no exceptions, all of the feedback from the participants was extremely positive. We look forward to incorporating many of the suggestions and observations into making our work here more efficient and higher quality. Carol Batman, INDesign LLC.
Thanks a lot for a great seminar. We really enjoyed it! We're already putting to use some of the ideas you gave us. J. Sarget, CSC
Thanks for the terrific seminar here at ALSTOM yesterday! It got rave reviews from a pretty tough crowd. Cheryl Saks, ALSTOM
Jack, it's been 6 months since you came here. This last project shipped within a week of prediction, with far more features than expected. The customer is thrilled and so is my boss. Thanks! F. Henry, CACI
Thanks so much for a great class! Now my co-workers think I'm the guru! Dana Woodring, Northrop Grumman
I would highly recommend your seminar to other programmers. Ed Chehovin, US Navy
Jack lectures internationally to conferences and businesses. He founded three electronics companies, including one of the largest embedded tool providers, and was a member of NASA's Super Problem Resolution Team, a small panel of experts formed to advise NASA in the wake of the Shuttle Columbia's loss. His extensive product development experience forged his unique approach to building better firmware faster.
Jack has helped hundreds of companies and thousands of developers on six continents improve their firmware and consistently deliver better products on-time and on-budget.
Do these situations sound familiar?
- Deadlines come and go yet the product still doesn't ship.
- You never really know the status of a project. It's almost "done" but new problems keep pushing out the ship date.
- "Creeping featurism" makes the product's design a moving target
- Bugs plague the entire development effort, consuming vast resources
- Post-release bugs continue to haunt the development team.
Most organizations fall into a fatalistic acceptance of these sorts of problems, never realizing that a number of well-known methods can eliminate much of the agony of product development.
The "twisted triad"- balancing three competing forces
Engineering is one of the few professions learned mostly on the job. Colleges prepare people with a fine theoretical background, but the skills needed to get a quality product to market come from mostly casual mentoring by co-workers. Why don't we train developers in the art of doing projects?
What is your department's most expensive resource? It's the one asset you have to get products to market: the developers' time. No doubt you replace and upgrade tools, compilers and the like from time to time. What are you doing to upgrade your skills, or the skills of your engineers?
With a bit of practice you can reduce bug rates - and tremendously speed product release.
In this course you'll learn how to get your products to market faster, with fewer defects. The presentation and recommendations are practical, immediately useful, and tightly focused on embedded system development.
Do those C/C++ runtime routines execute in a μs or week? This trig function is all over the map, from 6 to 15 ms. You'll learn to write real- time code proactively, anticipating timing issues before debugging.