Why Are We Still Struggling in the Golden Age of Embedded Systems Development?

We are arguably better equipped with software tools, processes, debuggers, and analyzers than ever before—so why are we still struggling?

The core problems remain the same: mixed expectations, poor communication, shifting priorities, and a lack of autonomy. What can we do today to improve outcomes for ourselves, our team, and our organization?

In this talk, I will share lessons learned from a significant project at the LEGO Group, where we successfully transitioned all PoweredUp motors and sensors from STM8 to STM32, on time and within budget.

What this presentation is about and why it matters

Why do teams still feel stuck when the tools are better than ever? Ralph Hempel uses a reflective, practical talk to look at that tension through the lens of embedded firmware work, moving from older debug setups to a detailed project case at LEGO. He mixes personal experience, process critique, and concrete examples from a low-friction development environment, including planning, documentation, CI/CD, and team collaboration. The focus is not on a universal recipe, but on what helped one real project move with less friction, which makes this especially useful for engineers and leads trying to improve how their teams actually work.

Who will benefit the most from this presentation

• Firmware engineers who feel delivery is always harder than it should be, even with modern tooling
• Tech leads who are trying to reduce friction without adding more process for its own sake
• Embedded managers who need a clearer way to discuss team workflow, trust, and confidence
• Developers working on cross-functional projects with hardware, firmware, and verification handoffs

What you need to know

No deep background is required, but the talk will land better if you already know the basics of embedded development and team workflows.

• Familiarity with firmware development and release work
• Some experience with version control and code review
• Basic awareness of CI/CD and automated testing
• Interest in documentation and team process

Glossary (terms used in this talk)

• CI/CD (Continuous Integration/Continuous Deployment): An automated pipeline practice for continuously integrating code changes, running verification, and optionally releasing software.
• TDD (Test-Driven Development): A development technique where tests are written before implementation and code is iterated until the tests pass.
• Burning platform: A compelling, urgent reason for action that justifies major change or project commitment.
• Liberating Structures: A catalog of facilitation micro-practices designed to make group interactions more participatory and productive.
• TRIZ: A facilitation exercise that asks a team how to make a situation fail spectacularly in order to surface risks, constraints, and hidden assumptions.
• Gitflow: A branching model for Git that uses long-lived branches such as develop and release branches to organize work.
• Trunk-based development: A source-control workflow where developers integrate changes into a single main branch frequently, typically with small, short-lived branches.
• Sprint goal: A short, explicit objective that defines what success looks like for the current iteration. It helps a team focus effort, adapt to changing conditions, and avoid overcommitting to lower-value work.

Toolbox (mentioned in this talk)

• Jira: A project tracking and issue management tool used for planning and workflow management.
• CppUTest: A unit testing framework designed for C and C++ code, including embedded software testing.
• Git: A distributed version control system for tracking changes in source code and coordinating collaborative development.
• Uncrustify: A source code formatter that automatically applies consistent code style rules across C, C++, and related languages.
• Sphinx: A documentation generation system commonly used to build structured technical documentation from source files.
• Read the Docs: A documentation hosting and publishing service that builds and serves project documentation from source repositories.

Final thoughts

Practical and reflective, this talk offers a useful mental model for why process, tooling, and teamwork can still feel brittle in embedded work. Viewers will come away with a clearer vocabulary for spotting friction, and a more grounded way to think about documentation, automation, and team habits in real projects. It will be especially helpful for firmware developers, tech leads, and engineering managers who want fewer heroic recoveries and more steady progress. The quiet message is that better tools matter, but the way a team works matters just as much.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.