The Agile Embedded Podcast

In this second part of our series on engineering organizations, Jeff and Luca explore how companies that build products should focus their efforts differently depending on their stage and scope. We start with startups and early-stage companies desperately searching for product-market fit, where the brutal truth is: quality doesn't matter yet. Your MVP should embarrass you—if it doesn't, you waited too long. We discuss the critical mental shift from throwaway prototypes to proper engineering once validation arrives, and why technical founders often fail by solving the wrong problem brilliantly. Moving up the ladder, we examine narrow-focus companies that have found their niche—like the German firm that does nothing but maintain a 100-year-old anchor chain machine, or specialists in medium-power electrical switches. These companies win through efficiency and deep expertise, but face existential risk if the market shifts. Finally, we tackle wide-focus companies introducing multiple product lines, where the challenge becomes running internal startups while managing established products, each requiring radically different approaches. The key insight: your focus must match your product's lifecycle stage, whether that's ruthless speed, cost optimization, or high-level process learning. Key Topics Notable Quotes "If you read the Lean Startup, they will explicitly say: if you weren't embarrassed by your MVP, you waited too long. It really has to be painfully flimsy because you cannot afford to do it well." — Luca "Quality doesn't even factor because you're very explicitly building mock-ups from chewing gum and paper mache. They are fully intended to be thrown away." — Luca "Getting that product-market fit is existential. You will die if you do not get it and get it relatively quickly." — Jeff Resources Mentioned The Lean StartupThe Mom TestThe Art of InnovationLuca's WebsiteJeff's Website You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

In this first part of a two-part series, Jeff and Luca explore how different types of service-oriented engineering organizations should focus their learning and improvement efforts. Drawing from their consulting experience, they examine three distinct categories: product development firms that turn client ideas into reality, engineering development firms that sell specialized technical expertise, and solo engineers who package all necessary knowledge into one person. The core insight: what you should focus on learning depends entirely on what you're actually selling. Product development firms need to master the entire client journey and product design process, not just engineering excellence. Engineering development firms must become technical wizards in a specific domain that clients actually value. Solo engineers face the challenge of needing deep expertise while wearing every business hat. Across all three types, the common traps are the same: focusing too much on craft and too little on client experience, failing to specialize, and not investing enough in teaching as marketing. Throughout the discussion, Jeff and Luca emphasize that for service firms, you are the product - and that changes everything about where you should direct your improvement efforts. The conversation is grounded in real experiences, including some cautionary tales about firms that tried to be everything to everyone. Key Topics Notable Quotes "The customers don't actually hire them for their engineering skills. They are sort of a given. But what such a product development firm should offer the client is guiding them through the development process, which they don't have enough skills for to do it on their own." — Luca "Engineering is not the point. The unit of work is delivering a working product to the client that satisfies their business case, that has a reasonable cost to manufacture, and that you feel confident your own client has validated their market." — Jeff "It's not that engineering is irrelevant, but rather that it's table stakes. This is just taken for granted, but what such a product development firm should offer is guiding them through the development process." — Luca "You almost can't be narrow enough. I remember our friend Philip Morgan having this example of a company that specializes in reviewing invoices of forklift repairs. This is what they do. They review forklift repair invoices. And they're doing very well apparently." — Luca "Teaching and giving information and solving problems publicly is the best form of marketing. It's not advertising. It's building trust with an audience." — Jeff Resources Mentioned Jeff Gable's websiteLuca Ingianni's websiteConnect With Us You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

In this episode, we sit down with Milica Kostic, an embedded software architect from Belgrade, Serbia, to discuss her journey from C/C++ to Rust and what it means for embedded development. Milica shares her experience adopting Rust in production environments, starting with an embedded Linux project using a microservice architecture that allowed for clean isolation of Rust code. We explore the practical realities of learning Rust as an experienced C/C++ developer - yes, there's a learning curve, and yes, the compiler will slap you on the wrist frequently. But Milica explains how the development experience, with cargo as a package manager and built-in tooling for testing and static analysis, makes the journey worthwhile. She's candid about where Rust shines (embedded Linux, greenfield projects) and where challenges remain (microcontroller support, IDE tooling, vendor backing). The conversation touches on the bigger question facing our industry: with memory safety becoming critical in our connected world, what role should Rust play in new embedded projects? While Milica takes a measured stance - acknowledging that C and C++ aren't going anywhere - she's clearly excited about Rust's potential, especially in safety-critical domains like medical devices. Whether you're Rust-curious or still skeptical, this episode offers a grounded perspective from someone who's actually shipped production code in Rust. Key Topics Notable Quotes "Learning Rust has also made me a better C++ developer as well. Once you get used to those rules, you apply them in C++ as well." — Milica "Just like writing Rust code is pleasant. It flows much nicer than or easier than it would with C++, for example. The way you organize your code, in my opinion, is also cleaner." — Milica "If you are developing Rust for embedded systems on microcontrollers, you need to be aware that there is no official vendor support. Everything currently is open source and driven by the community." — Milica "You definitely do not lose benefits of using Rust for the rest of your codebase when using a C library. That C library is isolated, and if there are some memory issues, then you know where to look." — Milica "I think most of the benefits come from starting with Rust in the first place. So having a clean slate, starting a new product, new project with Rust. That's where you see the most benefits." — Milica Resources Mentioned Milica's LinkedInMilica's talk on Rust at the Embedded Online Conference You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

We talk with Matt Trentini, Principal Software Engineer at Planet Innovation, about using MicroPython for professional embedded development—including medical devices. Matt shares how he was drawn back to embedded development after becoming jaded with traditional C-based workflows, and explains why MicroPython's interactive REPL and rapid development cycle have become game-changers for his team. We explore the practical realities of using an interpreted language on microcontrollers: how Planet Innovation uses it for Class B medical devices, what the performance trade-offs actually look like, and how features like the Unix port enable robust testing. Matt walks us through deployment considerations, explains how to integrate C code when needed, and shares compelling stories about real-time client demos that would be impossible in C++. Whether you're skeptical about high-level languages in embedded systems or curious about alternatives to traditional development workflows, this conversation offers a grounded, engineering-focused look at what MicroPython can—and can't—do in production environments. Key Topics Notable Quotes "It's hard to overstate how game changing the REPL is. Particularly as an embedded engineer, once you see that you can interactively talk to a peripheral, you can generate your own I2C, squirt it across and see what the peripheral does with it—suddenly driver development has just become easy to experiment with." — Matt Trentini "My trite answer is that MicroPython is slow—10 to 100 times slower than C in the interpreter. But my flip side answer is that it can always be made as fast as C because you can always drop into C to write things." — Matt Trentini "There was a moment in a recent project where we were discussing the workflow of a state machine with the client, and while we were on a call, another engineer was actually making changes to MicroPython code. Literally a couple minutes after we'd been hashing out the details, they showed the changes in the state machine using the REPL. The client was blown away—in 25 years of development, I have never had that kind of turnaround in C and C++." — Matt Trentini "If you want to make a good friend of your electronics engineers, give them a build of MicroPython that can run on their custom board. In the past, they would typically be waiting for weeks or sometimes months before a software resource could be assigned. Now I can turn around a MicroPython build in a day or two, and they can test I2C, GPIOs, and UARTs themselves." — Matt Trentini "The irony is that the people who have embedded C knowledge are actually the people that can benefit the most from MicroPython. It's like having a superpower—you understand what MicroPython is doing in the background, you know you're just effectively writing a lot less code." — Matt Trentini Resources Mentioned MicroPython Official SiteOpenMVPlanet InnovationCircuitPython You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

In this episode, Jeff and Luca tackle the unique challenges faced by solo embedded developers. Drawing from their own experiences as consultants, they explore why working alone makes it harder to maintain good development practices - from the constant pressure to multitask across different stakeholder demands, to the difficulty of wearing multiple hats as leader, manager, and contributor simultaneously. The conversation moves through common pitfalls: skipping documentation because "it's all in my head," letting code reviews slide, making questionable architecture decisions without a sounding board, and neglecting tools like simulators under time pressure. But this isn't just a catalog of problems - Jeff and Luca share practical strategies for staying disciplined, from creating mastermind groups with fellow solo developers to strategically hiring third-party reviewers for architecture decisions. They discuss how to push back on arbitrary deadlines, the value of enforcing process on yourself, and why sometimes the best productivity hack is spending money on training to force yourself to sharpen your skills. Whether you're a solo consultant, the only developer at a startup, or part of a small team, this episode offers honest insights into maintaining quality and sanity when you're working largely on your own. Key Topics Notable Quotes "When you're a solo developer, you have to be the leader, the manager, and the contributor for the software effort. Those are different roles and different skills." — Jeff "You must apply agility to agility. Inspect your process, figure out what works, what doesn't work. If something is annoying to you, either it's pointing you towards a real deficiency or it's just objectively a terrible process and you should change it." — Luca "It's really scary how effective rubber duck debugging is. You start to think of what the other person would answer, even though you're just talking to a rubber duck." — Jeff "Simple and easy are not the same things. Having good development practices, just like losing weight, is simple. It's just not easy." — Jeff "Dear listeners, have you ever paid with your own money for software development? Because I have. And it's really unnerving. You tell this developer to go do something and they just sort of disappear and you can hear the meter running." — Luca Resources Mentioned QP Real-Time Framework - Event-driven framework by Miro Samek for embedded systems, mentioned as a game-changing architecture choice for medical device development with active object patterns and hierarchical state machines Zephyr RTOS - Open-source real-time operating system for embedded devices, discussed as an important technology for solo developers to master for modern IoT and connected device projects Embedded Online Conference / Embedded Summit - Premier embedded systems conference offering both online and in-person training, including hands-on bootcamps for technologies like Zephyr RTOS, organized by Jacob Beningo and Stephane Boucher Agile Embedded Academy - Luca's newly launched training platform focused on applying agile methodologies specifically to embedded systems development, offering practical courses for embedded teams FDA Software Documentation Requirements - Regulatory documentation standards for medical device software including requirements specifications, architecture documents, detailed design, and test protocols required for FDA submissions Mob Programming Methodology - Collaborative development approach where entire team works on single task together, referenced as an alternative to traditional multitasking, promoted by Austin Chadwick and Chris You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at...

In this fascinating episode, we dive deep into the world of agile hardware development with Gregor Gross, a civil engineer who runs Alpha-board, a PCB design service company in Berlin, Germany. Gregor shares his unique perspective on applying agile principles to hardware projects, where you can't just hit compile and get a new increment. We explore the practical challenges of agile hardware development, from structuring contracts differently to breaking complex PCBs into testable modules and shields. Gregor discusses the importance of mixed hardware-software teams, the role of automated documentation, and why his engineers resist pair programming despite its proven benefits. The conversation also touches on the cultural barriers to adopting agile practices in traditional hardware companies and the innovative approaches needed to make agile hardware development work in a service provider context. Key Topics Notable Quotes "We are probably the only service provider in Germany that offers agile hardware development because I don't see so many people speaking about it." — Gregor Gross "Software is soft, hardware is hard. I was waiting to say that." — Gregor Gross "My experience from pairing was they work harder. They feel like they observe themselves... but there wasn't any mistakes. And actually they themselves said they were surprised by how much they did because they did more than twice what they expected." — Gregor Gross "It's better to have different shields and modules that have some of the functionality. And so you can start iterating through these functionalities and test them." — Gregor Gross Resources Mentioned Alpha-boardZephyr OS KiCadAndrew Greenberg's KiCon Presentation You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

In this special crossover episode with the brand-new Embedded AI Podcast, Luca and Jeff are joined by Ryan Torvik, Luca's co-host on the Embedded AI podcast, to explore the intersection of AI-powered development tools and agile embedded systems engineering. The hosts discuss practical strategies for using Large Language Models (LLMs) effectively in embedded development workflows, covering topics like context management, test-driven development with AI, and maintaining code quality standards in safety-critical systems. The conversation addresses common anti-patterns that developers encounter when first adopting LLM-assisted coding, such as "vibe coding" yourself off a cliff by letting the AI generate too much code at once, losing control of architectural decisions, and failing to maintain proper test coverage. The hosts emphasize that while LLMs can dramatically accelerate prototyping and reduce boilerplate coding, they require even more rigorous engineering discipline - not less. They discuss how traditional agile practices like small commits, continuous integration, test-driven development, and frequent context resets become even more critical when working with AI tools. For embedded systems engineers working in safety-critical domains like medical devices, automotive, and aerospace, the episode provides valuable guidance on integrating AI tools while maintaining deterministic quality processes. The hosts stress that LLMs should augment, not replace, static analysis tools and human code reviews, and that developers remain fully responsible for AI-generated code. Whether you're just starting with AI-assisted development or looking to refine your approach, this episode offers actionable insights for leveraging LLMs effectively while keeping the reins firmly in hand. ## Key Topics * [03:45] LLM Interface Options: Web, CLI, and IDE Plugins - Choosing the Right Tool for Your Workflow * [08:30] Prompt Engineering Fundamentals: Being Specific and Iterative with LLMs * [12:15] Building Effective Base Prompts: Learning from Experience vs. Starting from Templates * [16:40] Context Window Management: Avoiding Information Overload and Hallucinations * [22:10] Understanding LLM Context: Files, Prompts, and Conversation History * [26:50] The Nature of Hallucinations: Why LLMs Always Generate, Never Judge * [29:20] Test-Driven Development with AI: More Critical Than Ever * [35:45] Avoiding 'Vibe Coding' Disasters: The Importance of Small, Testable Increments * [42:30] Requirements Engineering in the AI Era: Becoming More Specific About What You Want * [48:15] Extreme Programming Principles Applied to LLM Development: Small Steps and Frequent Commits * [52:40] Context Reset Strategies: When and How to Start Fresh Sessions * [56:20] The V-Model Approach: Breaking Down Problems into Manageable LLM-Sized Chunks * [01:01:10] AI in Safety-Critical Systems: Augmenting, Not Replacing, Deterministic Tools * [01:06:45] Code Review in the AI Age: Maintaining Standards Despite Faster Iteration * [01:12:30] Prototyping vs. Production Code: The Superpower and the Danger * [01:16:50] Shifting Left with AI: Empowering Product Owners and Accelerating Feedback Loops * [01:19:40] Bootstrapping New Technologies: From Zero to One in Minutes Instead of Weeks * [01:23:15] Advice for Junior Engineers: Building Intuition in the Age of AI-Assisted Development ## Notable Quotes > "All of us are new to this experience. Nobody went to school back in the 80s and has been doing this for 40 years. We're all just running around, bumping into things and seeing what works for us." — Ryan Torvik > "An LLM is just a token generator. You stick an input in, and it returns an output, and it has no way of judging whether this is correct or valid or useful. It's just whatever it generated. So it's up to you to give it input data that will very likely result in useful output data." — Luca Ingianni > "Tests tell you how this is supposed to...

In this episode, Jeff interviews Luca about his intensive experience presenting at five conferences in two and a half days, including the Embedded Online Conference and a German conference where he delivered a keynote on AI-enhanced software development. Luca shares practical insights from running an LLM-only hackathon where participants were prohibited from manually writing any code that entered version control—forcing them to rely entirely on AI tools. The conversation explores technical challenges in AI-assisted embedded development, particularly the importance of context management when working with LLMs. Luca reveals that effective AI-assisted coding requires treating prompts like code itself—version controlling them, refining them iteratively, and building project-specific prompt libraries. He discusses the economics of LLM-based development (approximately one cent per line of code), the dramatic tightening of feedback loops from days to minutes, and how this fundamentally changes agile workflows for embedded teams. The episode concludes with a discussion about the evolving role of embedded developers—from code writers to AI supervisors and eventually to product owners with deep technical skills. Luca and Jeff address concerns about maintaining core software engineering competencies while embracing these powerful new tools, emphasizing that understanding the craft remains essential even as the tools evolve. Key Topics Notable Quotes "One of the hardest things to get an LLM to do is nothing. Sometimes I just want to brainstorm with it and say, let's look at the code base, let's figure out how we're going to tackle this next piece of functionality. And then it says, 'Yeah, I think we should do it like this. You know what? I'm going to do it right now.' And it's so terrible. Stop. You didn't even wait for me to weigh in." — Luca Ingianni "LLMs making everything faster also means they can create technical debt at a spectacular rate. And it gets a little worse because if you're not paying close attention and if you're not disciplined, then it kind of passes you by at first. It generates code and the code kind of looks fine. And you say, yeah, let's keep going. And then you notice that actually it's quite terrible." — Luca Ingianni "I would not trust myself to review an LLM's code and be able to spot all of the little subtleties that it gets wrong. But if I at least have tests that express my goals and maybe also my worries in terms of robustness, then I can feel a lot safer to iterate very quickly within those guardrails." — Luca Ingianni "Roughly speaking, the way I was using the tool, I was spending about a cent per line. Which is about two orders of magnitude below what a human programmer roughly costs. It really is a fraction. So that's nice because it makes certain things approachable. It changes certain build versus buy decisions." — Luca Ingianni "You can tighten your feedback loops to an absurd degree. Maybe before, if you had a really tight feedback loop between a product owner and a developer, it was maybe a day long. And now it can be minutes or quarters of an hour. It is so much faster. And that's not just a quantitative step. It's also a qualitative step." — Luca Ingianni "Some of my best performing prompts came from a place of desperation where one of my prompts is literally 'wait wait wait you didn't do what we agreed you would do you did not read the files carefully.' And I'd like to use this prompt now, even before it did something wrong. And then it apologizes as the first step. And I feel terrible because I hurt the LLM's feelings. But it is very effective." — Luca Ingianni "As you tighten your feedback loops, quality must be maintained through code review and tests. Test first, new feature, review, passing tests—you need to go through that red-green-refactor loop. You can just hopefully do it much more quickly, and maybe in slightly bigger steps than you did before manually." — Jeff Gable "A...

In this comprehensive episode, Luka Mustafa, founder and CEO of Irnas Product Development, provides an in-depth exploration of Zephyr RTOS and its transformative impact on embedded development. We dive deep into how Zephyr's Linux Foundation-backed ecosystem enables hardware-agnostic development, dramatically reducing the time spent on foundational code versus business-value features. Luka shares practical insights from five years of specializing in Zephyr development, demonstrating how projects can achieve remarkable portability - including running the same Bluetooth code on different chip architectures in just an hour, and even executing embedded applications natively on Linux for development purposes. The discussion covers Zephyr's comprehensive testing framework (Twister), CI/CD integration capabilities, and the cultural shift required when moving from traditional bare-metal development to this modern RTOS approach. We explore real-world applications from low-power IoT devices consuming just 5 microamps to complex multi-core systems, while addressing the learning curve challenges and when Zephyr might not be the right choice. This episode is essential listening for embedded teams considering modernizing their development practices and leveraging community-driven software ecosystems. Key Topics Notable Quotes "With Zephyr, porting a Bluetooth project from one chip architecture to another took an hour for an intern, compared to what would traditionally be months of effort." — Luka Mustafa "How many times have you written a logging subsystem? If the answer is more than zero, then it shouldn't be the case. Someone needs to write it once, and every three years someone needs to rewrite it with a better idea." — Luka Mustafa "The real benefit comes from doing things the Zephyr way in Zephyr, because then you are adopting all of the best practices of developing the code, using all of the subsystems to the maximum extent." — Luka Mustafa "You want to make sure your team is spending time on things that make money for you, not on writing logging, for example." — Luka Mustafa Zephyr ProjectiirnasCarles Cufi's Talk You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

Key Topics Notable Quotes "When you initially hear about mobbing, you think everybody's inactive, but there's a lot of excess thought capacity around programming that can happen - somebody can be thinking about refactorings while others are typing the solution." — Chris Lucian "If you're all there, that whole feedback loop can happen in 15 minutes as opposed to 15 days. It's like technical debt - you pay now or pay later, and if you pay later, it's going to be more expensive." — Austin Chadwick "We tend to have multiple releases a day all the way to production. Most mobs will deliver to production at least twice a day - four hours of work and then deliver to prod." — Chris Lucian Resources Mentioned Mob Mentality Show You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

Key Topics Notable Quotes "If you can run unit tests on your host and run your embedded code in a simulator on your PC, that's a pretty good indicator that you've successfully decoupled it from the hardware." — Jeff Gable "You need to understand that documentation is actually part of your product. It's not separate from your product made of curly brackets - it's one and the same thing." — Luca Ingianni "Typing is not the bottleneck. It's the problem solving. This is a method of problem solving together faster." — Chris Lucian "If you get the whole system in the room and in the same mob, things just start cranking. You're not waiting for anything because everyone you need is there." — Austin Chadwick Find the Mob Mentality Show at https://mobmentalityshow.podbean.com/ You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

From Prototype to Product: Navigating Hardware Manufacturing with Violet Su In this episode of the Agile Embedded Podcast, Luca speaks with Violet Su, Business Development Manager at Seed Studio, about the challenges and opportunities in hardware manufacturing. The conversation explores the realities of hardware development, from initial prototyping to mass production. Violet emphasizes the importance of getting products into users' hands quickly to gather feedback, even if they're not perfect. She highlights common pitfalls for newcomers to hardware manufacturing, including underestimating costs, certification requirements, and supply chain complexities. The discussion also covers the growing influence of AI in hardware development and how emerging connectivity technologies are shaping the future of embedded systems. Key Topics Notable Quotes "You might be able to design one and it really works when you have a sample or 10 samples, but when we talk about products, there are a lot of nuances that we really need to think about." — Violet Su "You can fail faster so that you can succeed faster. We couldn't make a perfect project and we shouldn't expect to make a perfect product." — Violet Su "When they give you the complaints early on, you will be very thankful, and they know you listened as well." — Violet Su "The projects that might take off either really solve the pain of some people, or get people excited because it's something new." — Violet Su "There's nothing better than getting customer complaints early on, so you don't get them later on." — Luca Ingianni Resources Mentioned Seed StudioOpenUC2Connect With Us violet@seed.cc seedstudio.com You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here

Luca and Jeff dive into how AI tools can supercharge embedded development workflows. Luca shares his extensive hands-on experience, while Jeff brings a fresh perspective as someone just starting to incorporate these tools. They explore how AI can help with coding, testing, and debugging - while emphasizing that good software engineering judgment remains crucial. The conversation is particularly timely since AI tools are evolving rapidly, unlike their usually more "evergreen" podcast topics. A key insight they discuss is that while AI tools offer amazing productivity boosts (much like IDEs did), they're not replacing experienced developers anytime soon. However, they raise interesting questions about the future job market for junior developers. Their take? Modern developers should absolutely embrace AI tools, but use them thoughtfully - especially when learning. Key Timestamps and Topics: 00:00:00 - Welcome and episode overview 00:00:43 - Why this topic won't age well (but that's okay!) 00:02:20 - Breaking down different AI coding tools 00:08:00 - Deep dive into aider and workflow integration 00:20:02 - Using AI for testing and test-driven development 00:27:00 - AI-assisted architecture work and its limitations 00:30:40 - How AI helps explore unfamiliar codebases 00:33:30 - Debugging with AI - pros and cons 00:38:50 - What this means for development jobs 00:43:59 - Using AI to learn new frameworks/languages 00:46:15 - Embedded Online Conference preview You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/ Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

## Key Topics * [00:30] Introduction to the listener's question about repository granularity in embedded development * [01:15] The listener's approach: separate repositories for different work products in safety-critical industries * [03:20] Luca's initial reaction and concerns about over-complication * [05:45] Discussion of monorepo approaches and configuration management * [08:10] The concept of micro-repositories and parallels to microservices * [11:30] Using feature flags and CI pipelines instead of repository separation ## Notable Quotes > "You're splitting something which ought to be joined together into different repositories and hiding whatever is happening within the repositories from the different users, from the different developers." — Luca Ingianni > "The risk of course is that you will not spot divergence early enough because people just don't merge because it's a chore and because things might break, and of course that is the point - the earlier you notice that something breaks, the easier it will be to fix it." — Luca Ingianni > "I'm willing to guarantee that you're going to get the architecture wrong at least on the first try. You think you're being really smart and you cut it up into a bunch of microservices or micro-repositories, and you're just going to get the boundaries wrong." — Luca Ingianni > "I would opt for fewer repositories and rather do configuration management within the repositories as opposed to between repositories. Use feature flags, use tagging, use whatever you want to insulate changes that might be breaking from the rest of the code base." — Luca Ingianni ## Resources Mentioned * John Taylor's Embedded Project Cookbook - A resource mentioned by the listener that discusses sequential events in embedded projects * Trunk-Based Development - Development methodology discussed throughout the episode * Minimum CD Podcast - Previous podcast episode referenced by the listener You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here

The episode discusses the concept of Minimum Viable Continuous Delivery (Minimum CD), which represents a counter-movement to heavyweight frameworks like SAFe. The hosts explore how Minimum CD provides a set of essential practices for successfully building software-based products without unnecessary complexity. The approach focuses on core principles rather than rigid frameworks, making it particularly relevant for embedded systems development. The discussion covers the fundamental requirements for continuous delivery, including automated testing, pipeline-driven deployments, and trunk-based development. The hosts emphasize that while these practices may seem challenging for embedded systems, they become increasingly important as devices become more sophisticated and connected. A key theme throughout the episode is the importance of building trust in the development process through automation, consistent practices, and cultural commitment. The hosts stress that while some practices may seem difficult to implement in embedded systems, the more challenging they are, the more valuable they become when successfully implemented. Timestamps and Topics: 00:00:00 - Introduction and overview of Minimum CD 00:02:00 - Discussion of Minimum CD as counter-movement to complex frameworks 00:03:45 - Continuous Integration fundamentals 00:15:35 - Pipeline as the only way to deploy 00:27:00 - Production-like test environments 00:29:45 - Rollback capabilities for connected devices 00:32:25 - Configuration deployment with artifacts 00:34:50 - Trunk-based development principles 00:39:30 - Automated testing requirements 00:41:10 - Maintaining delivered work integrity 00:45:55 - Wrap-up and closing thoughts Shownotes: Link to minimumcd.org: https://minimumcd.org/ Reference to Brian Finster as instigator of Minimum CD Reference to Raymond Chen's blog about Windows backward compatibility Reference to previous episode on trunk-based development Reference to interviews with Philip Johnston from Embedded Artistry Reference to interview with Francois from Mend Fault Link to Agile Embedded Slack group You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here

Key Topics * [03:00] Ryan's background in offensive cybersecurity and defense contracting * [04:30] The mindset and challenges of vulnerability research and hacking * [09:15] How security researchers approach attacking embedded devices * [13:45] Techniques for extracting and analyzing firmware * [19:30] Security considerations for embedded developers * [24:00] The importance of designing security from the beginning * [28:45] Security challenges for small companies without dedicated security staff * [33:20] Address Space Layout Randomization (ASLR) and other security measures * [37:00] Emulation technology for testing embedded systems * [45:30] Tulip Tree's approach to embedded system emulation and security testing * [50:15] Resources for learning about cybersecurity and hacking Notable Quotes > "When you're on the vulnerability research side, you're trying to find a time when the software does something wrong. When it does something unexpected." — Ryan Torvik > "Don't roll your own cryptography. Use a standard library for cryptography." — Ryan Torvik > "We're seeing that the maintenance costs are what are getting people now. You're expected to maintain this device, but now you got to be able to actually update the device." — Ryan Torvik > "It's so much more expensive to put security in after the fact if it's possible in the first place. Why is that even something that needs to be debated?" — Luca Ingianni Resources Mentioned [Tulip Tree Technology](tuliptreetech.com) - Ryan's company focused on embedded system security and emulation * IDA Pro - Interactive disassembler for firmware analysis * Binary Ninja - Interactive disassembler from Vector35 * Ghidra - NSA's open-source software reverse engineering tool * Microcorruption - Beginner-friendly CTF challenge for learning embedded system hacking * National Vulnerability Database - Public database of security vulnerabilities Things to do * Join the Agile Embedded Podcast Slack channel to connect with the hosts and other listeners * Check out Tulip Tree Technology's website for their emulation tools and security services * Try Microcorruption CTF challenges to learn about embedded system security vulnerabilities * Consider security implications early in your design process rather than as an afterthought * Use secure programming languages like Rust that help prevent common security issues You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here

Key Topics Notable Quotes "BDD is an additional layer of discipline on top of TDD. Dan North's goal was to get straight to the good stuff of TDD without getting into the pitfalls." — Steve "The key thing that BDD does by saying we're going to focus on behavior is you look at the API that you've written and you say, what can I do through the public API to affect this, to check the results and so forth?" — Steve "By having abstraction layers, you create your thin layer that's substitutable with either the real code on target, or with a test double off target." — Steve "Code coverage as a goal metric is not a good thing. Rather than using code coverage as just this almost dimensionless metric, use it as a signal to guide you." — Steve "By adhering very strictly to the simple rules of how to do BDD, by forcing yourself to the discipline of that strict adherence, it keeps you on track." — Steve Resources Mentioned James Grenning's bookSteve's blog postEmbedded Online TalkIan Cooper's video You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here

John Taylor returns to the podcast to discuss his new book "The Embedded Project Cookbook", co-authored with Wayne Taylor. The book serves as a practical guide for embedded systems development, providing recipes and techniques that John has refined over his 30+ year career. Unlike his previous book "Patterns in the Machine" which focused on software engineering best practices, this new book takes a more hands-on approach to project mechanics - from requirements gathering through release. The book provides opinionated guidance on setting up project infrastructure, managing requirements, software architecture, and release processes. While organized in a waterfall-like structure for clarity, it emphasizes the need for agility in embedded development. A key theme is establishing good practices early to make releases boring and predictable rather than chaotic. The content is valuable for different roles - from junior developers seeking context about the full development lifecycle, to technical leads implementing processes, to managers needing justification for development infrastructure investments. While the book presents John's specific approaches, he emphasizes that teams can adapt the recipes to their needs as long as they deliberately address the underlying challenges. Key Topics Discussed (Timestamps): 00:00:00 - Introduction and background on John Taylor 00:02:00 - Comparison to previous book "Patterns in the Machine" 00:06:00 - Target audience and use cases 00:15:00 - Software Development Plans and their value 00:20:00 - Foundation setup before coding begins 00:27:00 - Managing project variants and configurations 00:30:00 - Communication and collaboration practices 00:35:00 - Release management and ongoing development 00:40:00 - Iterative development cycles 00:43:00 - Book availability and contact information Links: Embedded Systems Cookbook: https://link.springer.com/book/10.1007/979-8-8688-0327-7 Patterns in the machine (the previous book): https://link.springer.com/book/10.1007/978-1-4842-6440-9 John's LinkedIn: https://www.linkedin.com/in/john-tanner-taylor/ You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here

In this episode, Jeff and Luca discuss trunk-based development, a software development practice where developers merge their work into the main branch (trunk) frequently - at least daily. They explain how this approach differs from traditional branching models like GitFlow, and address common objections and concerns. The hosts emphasize that while trunk-based development may seem risky, it actually reduces risk by exposing integration problems early and forcing teams to implement good engineering practices like automated testing and feature flags. The discussion highlights how trunk-based development acts as a "forcing function" that encourages better development practices, smaller changes, and more frequent collaboration between team members. They explain that while this approach originated in web development, it's equally applicable to embedded systems. The hosts cite research from the book "Accelerate" showing that trunk-based development is a predictor of high-performing software teams. The episode concludes by emphasizing that most objections to trunk-based development actually point to underlying process issues that need to be addressed, and that the benefits of early integration and feedback outweigh the perceived downsides. Timestamps: 00:00:00 - Introduction and topic overview 00:03:00 - Basic version control concepts and branching 00:08:00 - Definition and principles of trunk-based development 00:13:00 - Feature flags explanation and implementation 00:20:00 - Common objections to trunk-based development 00:27:00 - Application to embedded systems 00:34:00 - Benefits of trunk-based development 00:40:00 - Impact on team dynamics and collaboration 00:47:00 - Research backing and evidence from "Accelerate" Shownotes / Links: MinimumCD: https://minimumcd.org/ Accelerate: https://www.goodreads.com/book/show/35747076-accelerate The nvie branching model: https://nvie.com/posts/a-successful-git-branching-model/ You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here

The episode features a discussion with Mitch English, a product development team lead at Inertia, about using the QP (Quantum Platform) framework for embedded systems development. Mitch and Jeff recently collaborated on a medical device project where they successfully implemented QP. The framework, created by Miro Samek, implements the actor model with active objects running in their own threads and communicating via messages. This approach helps avoid common concurrency issues found in traditional RTOS implementations. The discussion covers how QP's hierarchical state machine framework makes it easier to manage complex state transitions and system behaviors. They share their experience using QP on a blood analyzer project, discussing how they structured the code with different layers of abstraction and maintained multiple test builds throughout development. The team found that QP's architecture helped make the system's complexity more manageable and testable. A key learning they shared was about event communication - while they initially used direct posting between active objects, they later realized that using the publish-subscribe pattern more extensively would have made testing easier and the system more flexible. They recommend starting with QP's simple examples and gradually building up complexity rather than trying to implement complex examples right away. Key Timestamps: 00:00:00 - Introduction and background 00:03:00 - Overview of QP framework and actor model 00:06:30 - Discussion of hierarchical state machines 00:19:30 - Project architecture and implementation approach 00:27:00 - Testing strategies and development process 00:30:00 - Team structure and collaboration 00:35:00 - Hardware/software integration 00:39:00 - Advice for getting started with QP 00:41:50 - About Inertia and contact information Links: Miro Samek's QP framework: https://www.state-machine.com/products/qp Miro's book on QP framework: https://www.state-machine.com/psicc2 QP GitHub repository with example code: https://github.com/QuantumLeaps/qpc-examples Inertia website: http://www.inertiapd.com/ Mitch English LinkedIn: https://www.linkedin.com/in/mitchellenglish/ You can find Jeff at https://jeffgable.com. You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here