Page de couverture de The Agile Embedded Podcast

The Agile Embedded Podcast

The Agile Embedded Podcast

Auteur(s): Luca Ingianni Jeff Gable
Écouter gratuitement

À propos de cet audio

Learn how to get your embedded device to market faster AND with higher quality. Join Luca Ingianni and Jeff Gable as they discuss how agile methodologies apply to embedded systems development, with a particular focus on safety-critical industries such as medical devices.2021-2025 Jeff Gable & Luca Ingianni
Épisodes
  • Terrible Habits of the Solo Developer
    Dec 16 2025
    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[00:00] Introduction: Can you do agile as a solo developer?[03:30] First principles of agile development and why they work for solo developers[06:15] Unique difficulties: Making progress in only one area at a time[10:45] Wearing three hats: Being leader, manager, and contributor simultaneously[15:20] Budget pressure and the challenge of 'nice to haves' that actually matter[22:30] The importance of delivering something palpable after the first sprint[28:00] Bad habit #1: No documentation because 'it's all in my head'[35:45] Bad habit #2: No code reviews and potential solutions[40:15] Using LLMs for code review: What works and what doesn't[44:30] Bad habit #3: Idiosyncratic or terrible code architecture[50:00] Bad habit #4: Not making it easy for other developers to take over[53:20] Bad habit #5: Neglecting simulators and development board support[57:00] Breaking bad habits: Working solo together through mastermind groups[62:30] Enforcing process on yourself and recognizing arbitrary deadlines[67:45] Applying agility to agility: Inspecting and adapting your own process[71:00] Sharpening the axe: Jeff's experience with the Embedded SummitNotable 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." — LucaResources MentionedQP 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 machinesZephyr 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 projectsEmbedded 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 BoucherAgile Embedded Academy - Luca's newly launched training platform focused on applying agile methodologies specifically to embedded systems development, offering practical courses for embedded teamsFDA Software Documentation Requirements - Regulatory documentation standards for medical device software including requirements specifications, architecture documents, detailed design, and test protocols required for FDA submissionsMob 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 hereAre you looking for embedded-focused trainings? Head to...
    Voir plus Voir moins
    54 min
  • Agile Hardware Development with Gregor Gross
    Dec 3 2025

    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
    • [02:30] Introduction to Alpha-board and agile hardware development services
    • [05:15] Defining agile principles: functionality-focused development and prioritization
    • [12:45] Contract challenges: moving from fixed-price to hourly service contracts
    • [18:20] Practical agile hardware: breaking PCBs into testable modules and shields
    • [25:10] Mixed teams and automated documentation for hardware-software collaboration
    • [32:40] The pair programming experiment: better results but team resistance
    • [38:55] Customer expectations and the need for end-user access in agile projects
    • [44:30] Version control and Git integration for hardware design workflows
    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-board - Gregor's PCB design and agile hardware development service company
    • Zephyr OS - Real-time operating system mentioned for prototyping with sample boards
    • KiCad - Open source EDA tool recommended for mixed teams and transparency
    • Andrew Greenberg's KiCon Presentation - Presentation on schematic style guides for better readability

    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/

    Voir plus Voir moins
    50 min
  • Crossover with Embedded AI Podcast
    Nov 18 2025
    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 work. You can have it write the test first and then evaluate the test. Using tests helps communicate - just like you would to another person - no, it needs to function like this, it needs to have this functionality and behave in this way." — Ryan Torvik > "I find myself being even more aggressively biased towards test-driven development. While I'm reasonably lenient about the code that the LLM writes, I am very pedantic about the tests that I'm using. I will very thoroughly review them and really tweak them until they have the level of detail that I'm interested in." — Luca Ingianni > "It's really forcing me to be a better engineer by using the LLM. You have to go and do that system level understanding of the problem space before you actually ask the LLM to do something. This is what responsible people have been saying - this is how you do engineering." — Ryan Torvik > "I can use LLMs to jumpstart me or bootstrap me from zero to one. Once there's something on the screen that kind of works, I can usually then apply my ...
    Voir plus Voir moins
    55 min
Pas encore de commentaire