Where can I listen to this podcast?

This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.

Hard Boiled Software

Claim This Podcast

by Dave Laribee

7 episodes

Updated Daily

Accepts GuestsHas Sponsors

Podcast Overview

Guest stories and viewpoints from the gritty streets of software engineering. <a href="https://newsletter.nerdnoir.com?utm_medium=podcast">newsletter.nerdnoir.com</a>

Language

🇺🇲

Publishing Since

1/14/2026

Visit Website View on Apple Podcasts RSS Feed

1 verified contact email on file for Hard Boiled Software

Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.

See contact details

Recent Episodes

June 17, 2026

"Mapping Your Architecture" with Simon Brown

Simon Brown is the creator of the C4 model for Visualising Software Architecture and the founder of Structurizr, the original developer-friendly “diagrams as code” tooling for version-controlled architecture documentation. An independent consultant based in Jersey, he has spent 15+ years helping hundreds of organizations across roughly 40 countries communicate their software architecture more clearly. His new book, “<a target="_blank" href="https://www.oreilly.com/library/view/the-c4-model/9798341660113/">The C4 Model: Visualizing Software Architecture</a>”, arrived from O’Reilly this month.Episode OverviewWhy have software architects, declared dead a decade ago, suddenly turned up again on client org charts? And how did a set of plain block diagrams Simon Brown used to sketch for his own day job become a whiteboard standard you can spot everywhere from Miami to London to Mumbai?Simon tells the origin of C4 with characteristic modesty (he calls it “really boring”). It started in mid-2000s London, where he ran architecture workshops, looked at the diagrams people drew, and realized he couldn’t understand any of them. With UML on its way out and no appetite to bring it back, he taught people the block diagrams he already used at the office. That became C4: four levels of abstraction, one at a time, with a Google Maps-style zoom from a broad system context into containers, components, and code.From there the conversation ranges across the architecture revival and what’s driving it (compliance gaps, lost water-cooler knowledge, and a flood of AI-generated code nobody understands), why Simon refused to build a drag-and-drop editor and made a text-based DSL instead, the deployment diagram he thinks is the most slept-on view in the whole model, and a candid comparison of how developer cultures differ on either side of the Atlantic. It’s a clear-eyed, plain-spoken look at the craft of drawing software so other people can actually read it.Links & ResourcesGuest Links* <a target="_blank" href="https://simonbrown.je/">Simon Brown’s website</a>* <a target="_blank" href="https://c4model.com/">The C4 model</a>* <a target="_blank" href="https://structurizr.com/">Structurizr</a> and the <a target="_blank" href="https://docs.structurizr.com/">Structurizr docs</a>* <a target="_blank" href="https://www.oreilly.com/library/view/the-c4-model/9798341660113/">The C4 Model: Visualizing Software Architecture</a> by Simon Brown (O’Reilly, 2026) — the rewritten and expanded successor to his self-published LeanPub C4 book; first six chapters are in early access* <a target="_blank" href="https://leanpub.com/software-architecture-for-developers">Software Architecture for Developers</a> by Simon Brown (Leanpub)* <a target="_blank" href="https://www.linkedin.com/in/simonbrownjersey/">Simon on LinkedIn</a>* <a target="_blank" href="https://bsky.app/profile/simonbrown.je">Simon on Bluesky</a>* <a target="_blank" href="https://x.com/simonbrown">Simon on X</a>Books & Articles Mentioned* <a target="_blank" href="https://erinmeyer.com/book/">The Culture Map: Breaking Through the Invisible Boundaries of Global Business</a> by Erin Meyer — the book Dave references on cross-cultural communication and negotiation styles, which maps how different cultures approach meetings and deals (best guess at the title Dave couldn’t recall in the moment; worth confirming before publishing)Tools, Frameworks & Concepts* <a target="_blank" href="https://docs.structurizr.com/dsl">Structurizr DSL</a> — a lightweight, text-based domain-specific language for defining a C4 model as code; a wrapper over the original Structurizr for Java library, built during COVID lockdown* <a target="_blank" href="https://modelcontextprotocol.io/docs/getting-started/intro">Model Context Protocol (MCP)</a> — Simon added MCP tooling that runs validation and parsing so an LLM can read the error messages and fix its own invalid DSL* <a target="_blank" href="https://plantuml.com/">PlantUML</a> — text-based diagramming tool; Structurizr can export views to it* <a target="_blank" href="https://mermaid.js.org/">Mermaid</a> — diagrams-as-code tool with a C4-style syntax that doesn’t enforce C4 semantics or view rules* UML — the OG modeling notation that fell out of favor after the Agile Manifesto, leaving the gap C4 filled* <a target="_blank" href="https://c4model.com/abstractions">The C4 abstractions</a> — system context, container, component, and code, plus the supporting system landscape, dynamic, and deployment diagramsTopics & Key PointsThe "Boring Origin Story of C4Simon traces C4 back to the architecture workshops he ran in mid-2000s London, where he discovered he couldn’t make sense of the diagrams participants drew. With UML already on the way out, he simply taught the block diagrams he used in his own day job.Key points:* The work grew out of consulting: growing a consultancy meant creating more tech leads and architects, so Simon started teaching people how to move into those roles* C4 is “a formalization of the block diagrams” he drew in a post-UML world, shaped over years of feedback rather than designed as an invention* The name stuck even though most teams use only the top two levels; Simon jokes it could just as well be called “C2 plus two optional levels”One Level at a TimeThe main move with C4 is to stop putting everything on one page and instead focus on a single level of abstraction at a time, zooming in Google Maps style from the system context down toward the code.Key points:* The “everything on one page” everything-diagram puts almost everyone off: non-technical stakeholders, infrastructure folks, and product owners all tune out* Slicing the picture into levels invites more people to the party: business and UX people engage with the context diagram because they’re thinking about how users reach their goals, and infrastructure and DevOps people gravitate to the container diagram* The container diagram closes the gap between dev and ops who want to collaborate but speak different languages; network engineers have told Simon that the diagram finally let them understand what the developers actually hand over to run and monitor* Code-level diagrams are almost never drawn (Simon has done it once), and even component diagrams are niche, most useful when planning a service extraction from a monolith or arranging a new small-to-medium monolithThe Architecture RevivalDave notes that architect roles are reappearing among clients in 2026 after years of backlash against “ivory tower” architects. Simon offers two theories for why.Key points:* Theory one: organizations that swung from heavy upfront design all the way to “working software over comprehensive documentation” overcorrected, and now fail compliance audits, hold critical knowledge in tribal silos, and don’t fully understand the software running their business; COVID made it worse by erasing water-cooler knowledge transfer* Theory two: AI and vibe coding produce thousands of lines of code nobody understands, can review, or knows how to fit into existing systems, nudging teams back toward some planning, not months of it, but enough to bring structure* Dave frames the shift as planning and feedback loops moving left up the value stream, now reaching into architecture and product conversations* A good plan plus small, reviewable slices (build a slice, then pause and review) is producing strong results in Dave’s own workflowDiagrams as Code with StructurizrSimon explains why he turned down a WYSIWYG editor for C4 and instead built a text-based DSL, and why that choice has aged well in the AI era.Key points:* He’s a developer. He likes text, version control, and diffs. Drag-and-drop canvases give a low barrier and quick wins but become unmanageable at scale (picture adding one system that connects to forty others by ticking boxes in a GUI)* The earliest Structurizr tooling required writing Java, which few people wanted, so during lockdown Simon built the lightweight Structurizr DSL as a wrapper over the Java library; the first version took about a week* The DSL is model-based: one text file can drive multiple views with consistent styling, and relationships defined at lower levels bubble up automatically to reduce what you have to write* All this turns out to be AI/LLM-readable too; Simon added MCP tooling so an LLM can run validation and parsing, read the error messages, and fix its own invalid output* Unlike Mermaid, which offers a C4-style syntax without understanding C4’s semantics or view rules, the Structurizr DSL bakes the rules in and won’t let you mix abstraction levels; you can still export to PlantUML or Mermaid when your toolchain needs themThe Slept-On DiagramsBeyond the four static levels, Simon walks through the supporting views people tend to overlook, and names his favorite underrated one.Key points:* The system landscape diagram is essentially a context diagram without a single-system focus, a wider view of the world around you* The dynamic diagram shows how one feature works at runtime as a set of collaborations; it’s genuinely useful but underused, and the trick is to document recurring patterns rather than drawing one per feature* Simon’s pick for most slept-on is the deployment diagram; the common mistake is superimposing the production cloud environment onto the container diagram, when the container diagram should stay deployment-environment-agnostic with a separate deployment diagram per environment* Simon’s static-content example makes it concrete: the same set of files is mounted into an NGINX Docker container in development and pushed to an S3 bucket served via Cloudflare in production* On representing change over time, the options range from current and future-state copies, to additive DSL extensions, to a future-state tagging mechanism that drives separate views, to color-coding (with a caution to watch for red-green color deficiency)Two Sides of the AtlanticThe episode closes on a frank comparison of developer cultures, with Dave offering the American read and Simon the European one. Key points:* Dave’s take: US teams feel practical, results-driven, and money-focused, while the European and UK scenes lean more intellectual and ideas-driven* Simon, who has run the large majority of his workshops in and around Europe, sees more friction, overhead, and bureaucracy in the typical US enterprise, and a stronger learning culture inside European organizations* He caveats the comparison heavily, noting he has never run a workshop in California or Silicon Valley and is deliberately carving that out* Dave mentioned a book on cross-cultural communication and negotiation styles, “<a target="_blank" href="https://www.amazon.com/When-Cultures-Collide-Leading-Across/dp/147368482X">When Cultures Collide: Leading Across Cultures (4th Edition)</a>” by Richard D. Lewis. It contains some interesting visualizations about how different cultures run meetings, negotiations, and other business events.Hard Boiled Software is hosted by <a target="_blank" href="https://www.linkedin.com/in/laribee/">Dave Laribee</a>. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://newsletter.nerdnoir.com?utm_medium=podcast&utm_campaign=CTA_1">newsletter.nerdnoir.com</a>

May 26, 2026

"Behavior Change at Scale" with Jimmy Parker

Jimmy Parker is the Founder and Chief Transformation Officer of <a target="_blank" href="https://peaq.co/">Peaq</a>, where he helps companies create fast, lasting transformation at scale. A graduate of the U.S. Naval Academy who served 11 years as a Marine Corps helicopter pilot, Jimmy went on to earn a PhD in developmental psychology applied to organizational transformation from Fielding Graduate University. Before founding Peaq, he led organizational development at The Home Depot and Kaiser Permanente, where he spent the better part of two decades studying what actually changes on-the-job behavior, and just as importantly, what doesn’t.Episode DescriptionWhat if almost everything we spend on training never makes it back to the job? That isn’t rhetorical. The research Jimmy Parker has been chasing for 20 years puts the application rate of traditional training somewhere between zero and nine percent. In this conversation, Jimmy traces the path from his frustration as a classroom trainer to a methodology he calls micro experiences, a way of changing behavior at scale by leading with doing rather than knowing.Jimmy’s career arc is a study in contrasts. started in the Marine Corps as an attack helicopter pilot, then carried that low tolerance for theater into corporate L&D. He has studied behavior change wherever the lessons live, including habit science, marketing, addiction recovery, even religious conversion, and he has spent years pressure-testing what survives contact with a real organization. The result is a system designed around the gap between knowledge, behavior, and habit, and a specific format for closing it: a 45-minute action in the flow of work, paired with a reflection question, followed by a small-group conversation, repeated weekly for three to six months.We get concrete in this episode. Jimmy walks through two micro-experiences he uses in the field: the “judo move” for product teams stuck in order-taker mode, and a decision audit for executives who say they want to grant autonomy but never quite manage to. We talk about why most OKR programs would score a D, why simple isn’t easy when you’re designing for behavior change, and why Jimmy ultimately frames this work as a question of equity, because the people who get the highest-quality development today are almost always the rare and privileged few.Links and ResourcesGuest Links* <a target="_blank" href="https://peaq.co/">Peaq</a> — Jimmy’s consulting practice* <a target="_blank" href="https://www.linkedin.com/in/-jimmy-parker">Jimmy Parker on LinkedIn</a>* Email Jimmy directly: jimmy@peaq.coTools, Frameworks, and Concepts* Micro Experiences — Jimmy’s framework for behavior change at scale, structured as 45-minute on-the-job actions with reflection and small-group debrief* The Four-Step Weekly Cycle — adapt, do, reflect, discuss* Experiential Learning — the tradition of learning by doing and reflecting, traceable to John Dewey* Declarative vs. Implicit Knowledge — the distinction between what can be taught in a classroom and what can only be learned through doing* Unconscious Competence — the final stage in the progression from ignorance to habit* <a target="_blank" href="https://www.whatmatters.com/faqs/okr-meaning-definition-example">OKRs (Objectives and Key Results)</a> — referenced as an example of how knowing the framework rarely translates to doing it wellPeople Referenced* <a target="_blank" href="https://en.wikipedia.org/wiki/John_Dewey">John Dewey</a> — the philosopher widely regarded as the father of experiential learning, often paraphrased: "We do not learn from experience, we learn from reflecting on experience.”Topics DiscussedFrom the Cockpit to Behavior ChangeJimmy opens with the throughline of his career: a love of leadership picked up in the Marine Corps, sharpened by years of running leadership training programs, and ultimately reshaped by the uncomfortable realization that classroom training rarely changes what people actually do on the job. That frustration sent him on a 20-year hunt across disciplines for what really drives behavior change.Key points:* The military taught Jimmy a low tolerance for things that don’t work, a standard he has carried into executive development* After running thousands of people through classrooms, Jimmy noticed the change rarely manifested on the job* His study took him well outside L&D, into habit science, addiction recovery, religious conversion, and consumer marketing, looking for what consistently moves behavior* The work eventually focused on executive behavior change, because the cultural barriers that block agile teams often exist above the teamWhy Traditional Training Falls ShortTraining is built on a single assumption: if people knew differently, they would do differently. That assumption holds for simple knowledge gaps and breaks down almost everywhere else. Jimmy is direct about the implications, including that the application rate for traditional training tops out at around 9%.Key points:* Studies from Harvard, MIT and others put the percentage of training participants who properly apply what they learned between zero and nine percent* Knowledge transfer is the right move for simple gaps; for complex, contextual, or culturally rooted behaviors, it almost never gets you to adoption* Agile talk is the common tell: organizations describe themselves in agile terms while their actual norms, requirements flow, and decision rights tell a different story* Most OKR programs score a D or C when measured against best practice, even when the people running them teach OKRs for a livingKnowledge, Behavior, HabitJimmy keeps his definitions deliberately simple because the value is in the progression rather than the taxonomy. Knowing is what you can recall. Behavior is what you can be observed doing in a given moment, including how you speak. Habit is what you do consistently, without conscious thought, even when old patterns are pulling you backward.Key points:* The path from ignorance to habit runs through a stage of effortful, high-cognitive-load doing before the new behavior becomes automatic* Most behavior change interventions stop at knowing and hope the rest takes care of itself* Speech counts as behavior, which is part of why team communication and conflict patterns are so hard to change* The endpoint is unconscious competence, and getting there takes deliberate reps over timeExperience as the Lead, Not LearningWhen Dave and Jimmy were planning the episode, Jimmy specifically pushed back on using the word learning to describe his work. The reason matters. Leading with experience is a wager that doing first, then reflecting, gets you further on the hard problems than thinking your way to a new way of acting.Key points:* Declarative knowledge can be taught; the tacit, contextual knowledge of when and how to adapt can really only be learned through reps and reflection* Jimmy borrows from Dewey: experience by itself isn’t enough; the learning lives in structured reflection on the experience* “Do we think ourselves into a new way of acting, or act ourselves into a new way of thinking?” Both work, but the second is consistently underused* For deeply rooted behaviors, especially with senior leaders, the experiential path tends to be the only one that landsAnatomy of a Micro ExperienceJimmy walks through two real examples. The first is the “judo move,” a one-pager for product teams stuck in order-taker mode, offering a handful of responses to use when a stakeholder hands them features without context. The second is the decision audit, where executives track every decision they make for a week and score each on a one-to-five scale of whether someone else should have owned it.Key points:* A micro experience has two non-negotiable components: micro, meaning it fits in 45 minutes or less, and experiential, meaning it happens in real work, not in a simulation or a classroom* Each micro experience runs on a four-step weekly cycle: adapt it to your context, do it, reflect using a designed question, then debrief with a small group of five or six peers* The decision audit consistently surfaces hidden patterns: leaders score their own decisions and realize how many they’re holding onto, and why* Designing micro experiences turns out to be much harder than it looks; Jimmy describes it as something close to a PhD-level design skill when the targets are seasoned executives or deeply rooted normsScaling Without Scaling CostThe scalability claim for micro experiences isn’t about how long they run; it’s about how cheap they are to deliver and how small their administrative footprint stays. Jimmy has run programs of 30,000 people that needed just over one full-time person to administer.Key points:* Programs run a minimum of three months and a maximum of six, with intentionality and engagement designed in from the start* The facilitator role is deliberately designed for moderately skilled coaches with about two hours of training, because certified agile coaches don’t scale to cross-functional transformations* Engagement design matters: opt-in versus opt-out, executive sponsorship, accountability mechanisms, and incentives all materially affect the 90% application rate Jimmy targets* Once an organization learns how to build these in-house, the cost runs around a tenth of traditional trainingDemocratizing Deep DevelopmentThe conversation closes on the purpose driving the work. Programs that consistently change behavior in lasting ways do exist, but they have historically been reserved for executives and high-potentials because they’re expensive. Jimmy frames the cost barrier as an equity problem, and micro experiences as one answer to it.Key points:* The highest-quality development has historically been a privilege, available only to a small slice of any organization* Jimmy describes the goal as deep development at scale, getting the impact of high-touch executive programs to many more people* Anyone can start experimenting with the approach on their own; the real lift is in designing micro experiences well enough to drive sticky change* For organizations that want the full system, Peaq offers a multi-step certification path that ends with clients running their own programs under licenseHard Boiled Software is hosted by <a target="_blank" href="https://www.linkedin.com/in/laribee/">Dave Laribee</a>. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://newsletter.nerdnoir.com?utm_medium=podcast&utm_campaign=CTA_1">newsletter.nerdnoir.com</a>

April 14, 2026

"Event Modeling: The Blueprint for Building Maintainable Software" with Adam Dymitruk

Adam Dymitruk is the creator of event modeling and the CEO and founder of <a target="_blank" href="https://adaptechgroup.com/">Adaptech Group</a>, a consultancy that builds information systems using event sourcing and event modeling. A software developer with over three decades of experience, Adam is a core contributor to CQRS and event sourcing theory and practice since 2008, a top 0.1% Stack Overflow contributor, and one of the original voices in the ALT.NET movement. He’s currently writing the definitive book on event modeling, with a companion booklet due out first.Episode DescriptionWhy do we keep building software that breaks every time we add a feature? And what if there were a way to describe a system so clearly that business people, designers, and developers could all work from the same blueprint?In this conversation, Adam Dymitruk traces a path from the rebellion of the ALT.NET movement in the mid-2000s through the rise of domain-driven design, the discovery of event sourcing, and the creation of event modeling, a notation and process for describing information systems that has quietly become one of the most practical innovations in modern software design. Along the way, Adam and Dave revisit shared history: the nHibernate Mafia, the fight against sealed classes, the moment when Martin Fowler’s 2005 article on event sourcing planted a seed that would take years to fully grow, and the community of developers who decided they’d rather take care of each other than wait for permission from Microsoft.The heart of the episode is Adam’s case for why event sourcing and event modeling eliminate entire categories of problems that most teams accept as inevitable: the hockey-stick cost curve, the coupling that turns codebases into houses of cards, the schema migrations that become existential crises, and the tech debt that accumulates because every new feature has to touch code that already works. Adam explains how Adaptech Group has built its business on fixed-cost contracts and free bug fixes, not as a loss leader but because the architecture genuinely makes it possible. The conversation closes with Adam’s view on AI as the next irreversible point of no return, why event modeling provides exactly the kind of specification that AI needs to generate good code, and a first look at the two books he’s writing to bring this work to a wider audience.Links & ResourcesGuest Links* <a target="_blank" href="https://adaptechgroup.com/">Adaptech Group</a> — Adam’s consultancy* <a target="_blank" href="https://eventmodeling.org/">Event Modeling</a> — the official site for the event modeling methodology* <a target="_blank" href="https://eventmodeling.org/posts/what-is-event-modeling/">Event Modeling: What is it?</a> — Adam’s original 2019 article* <a target="_blank" href="https://www.linkedin.com/in/eventmodeling/">Adam Dymitruk on LinkedIn</a>* <a target="_blank" href="https://github.com/adymitruk">Adam Dymitruk on GitHub</a>* <a target="_blank" href="https://discord.com/invite/Sw4MvagftJ">Event Modeling Discord Community</a>Books & Articles Mentioned* <a target="_blank" href="https://leanpub.com/eventmodeling-and-eventsourcing">Understanding Eventsourcing</a> by Martin Dilger — the first book combining event modeling and event sourcing* <a target="_blank" href="https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215">Domain-Driven Design</a> by Eric Evans — the influential “blue book” both Adam and Dave reference on multiple occasions* <a target="_blank" href="https://www.domainlanguage.com/ddd/reference/">Domain-Driven Design Reference</a> by Eric Evans — the companion booklet that Adam credits as a model for his own booklet approach* <a target="_blank" href="https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052">Working Effectively with Legacy Code</a> by Michael Feathers — cited by Adam as a model for the reference-pattern format of his upcoming book* <a target="_blank" href="https://martinfowler.com/eaaDev/EventSourcing.html">“Event Sourcing”</a> by Martin Fowler — the December 2005 article that introduced Adam to event sourcingTools, Frameworks & Concepts* <a target="_blank" href="https://martinfowler.com/eaaDev/EventSourcing.html">Event Sourcing</a> — an architectural pattern of storing state changes as an immutable sequence of events* <a target="_blank" href="https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs">CQRS</a> (Command Query Responsibility Segregation) — a pattern for separating read and write models* <a target="_blank" href="https://www.domainlanguage.com/">Domain-Driven Design</a> — Eric Evans’ approach to software development that became the intellectual home for event sourcing in the .NET world* <a target="_blank" href="https://www.eventstorming.com/">Event Storming</a> — Alberto Brandolini’s workshop format that influenced event modeling’s collaborative approach* <a target="_blank" href="https://www.hanselman.com/blog/hanselminutes-podcast-104-dave-laribee-on-altnet">ALT.NET </a>— the mid-2000s .NET developer community that championed open source, TDD, and better practices* <a target="_blank" href="https://en.wikipedia.org/wiki/Test-driven_development">Test-Driven Development</a> (TDD) — discussed at length, including Adam’s controversial position that event sourcing eliminates the need for it* <a target="_blank" href="https://cucumber.io/">Cucumber</a> — BDD testing tool that Adam used before discovering that events themselves serve as specifications* <a target="_blank" href="https://github.com/storyteller/storyteller">Storyteller</a> — Jeremy Miller’s graphical DSL testing framework for .NET that Adam used extensively for specification by example* <a target="_blank" href="https://nunit.org/">NUnit</a> — Charlie Poole’s open source .NET testing framework, a counterpart to Java’s JUnit* <a target="_blank" href="https://nhibernate.info/">nHibernate</a> — the open source .NET ORM ported from Java’s Hibernate; central to ALT.NET’s origin story (originally nicknamed the “nHibernate Mafia”)* <a target="_blank" href="https://javapro.io/2025/10/28/dynamic-consistency-boundaries/">Dynamic Consistency Boundary</a> — an evolution beyond DDD aggregates for managing consistency in event-sourced systems* <a target="_blank" href="https://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084">Specification by Example</a> / <a target="_blank" href="https://dannorth.net/blog/introducing-bdd/">Behavior-Driven Development</a> — the testing and specification approaches that preceded event modeling* <a target="_blank" href="https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle">Open/Closed Principle</a> — referenced by Adam in the context of event sourcing’s add-only architecture* <a target="_blank" href="https://www.cursor.com/">Cursor</a> — AI coding tool Adam used to demonstrate that event model screenshots produce correct implementations on the first try* Unix Philosophy — invoked by Dave to describe the component architecture that event sourcing enables: many specific tools that each do one thing wellPeople Referenced* <a target="_blank" href="https://www.eventstore.com/">Greg Young</a> — CQRS and event sourcing pioneer, longtime collaborator* <a target="_blank" href="https://eventide-project.org/">Scott Bellware</a> — Founder of the Eventide project and co-founder of ALT.NET* <a target="_blank" href="https://martinfowler.com/">Martin Fowler</a> — author of the 2005 event sourcing article* <a target="_blank" href="https://www.domainlanguage.com/">Eric Evans</a> — author of Domain-Driven Design* <a target="_blank" href="https://michaelfeathers.silvrback.com/">Michael Feathers</a> — author of Working Effectively with Legacy Code (<a target="_blank" href="https://newsletter.nerdnoir.com/p/hbs-001-michael-feathers">also former podcast guest</a>)* <a target="_blank" href="https://www.eventstorming.com/">Alberto Brandolini</a> — creator of Event Storming* <a target="_blank" href="https://www.linkedin.com/in/martindilger/">Martin Dilger</a> — author of Understanding Eventsourcing* <a target="_blank" href="https://jeremydmiller.com/">Jeremy Miller</a> — creator of the Storyteller testing framework* Mike Stockdale — creator of SpecSharp, from Calgary* <a target="_blank" href="https://github.com/CharliePoole">Charlie Poole</a> — creator of NUnit* <a target="_blank" href="https://serialseb.com/">Sebastian Lambla</a> — .NET open source contributor whose work was famously overwritten by Microsoft* <a target="_blank" href="https://www.hanselman.com/">Scott Hanselman</a> — referenced in the context of ALT.NET’s reach into the Microsoft communityTopics DiscussedThe ALT.NET Rebellion and Finding Your PeopleAdam and Dave open by tracing their shared history in the ALT.NET movement, a community of .NET developers who pushed back against Microsoft’s top-down approach to software development in the mid-2000s. What started as frustration with sealed classes, proprietary tooling, and the “embrace, extend, extinguish” mentality became a proving ground for open source, test-driven development, and the architectural ideas that would shape both of their careers.Key points:* ALT.NET (originally nicknamed the “nHibernate Mafia”) was born from developers needing to take care of each other because Microsoft wasn’t supporting the open source community* The community brought together TDD practitioners, open source advocates, and domain-driven design enthusiasts, creating the conditions for ideas like event sourcing to gain traction* Figures like Sebastian Lambla experienced the worst of Microsoft’s competitive stance, having their open source work overwritten overnight by official Microsoft alternatives* Both Adam and Dave credit ALT.NET as the environment where their points of view coalesced, particularly around DDD and event-driven architecturesFrom Domain-Driven Design to Event SourcingThe conversation traces how DDD provided the intellectual soil for event sourcing to take root, beginning with Martin Fowler’s 2005 article and evolving through Adam’s own experiments writing his first event store in 2009. Adam describes the shift from thinking about domain models and objects to thinking about state changes, facts, and immutable ledgers.Key points:* Adam wrote his first production event store in 2009 as a single page of C# code, proving the simplicity of the approach* The key insight: treat information the way accountants treat money, with full accountability and no erasures* Specification by example and BDD, while valuable stepping stones, became unnecessary once events themselves served as human-readable specifications* The community continues to evolve; practices like dynamic consistency boundaries are replacing traditional DDD aggregates, and event versioning through upcasters is giving way to handling multiple event versions directly in read modelsEvent Modeling: The Swiss Army KnifeAdam delivers his pitch for event modeling: a notation and process for describing information systems that looks like a sideways storyboard, captures state changes as events in plain English, and deliberately excludes implementation details. Born from the realization that his team at Adaptech was already doing something distinctive (they just thought they were doing BDD really well), event modeling was first formally written down at the Event Storming summit in 2018.Key points:* Event modeling uses only three moving pieces and four patterns based on two ideas; it takes minutes to explain and the rest is learned in practice* No branching logic in workflows; the notation sticks to a storyline by example because human minds remember stories far better than they remember graphs* The UX/UI is a first-class citizen in an event model, not an afterthought, because every system is ultimately built for human beings looking at an interface* Event modeling functions as a blueprint comparable to architectural plans for a building: the plumber, the carpenter, and the electrician all work from the same documentThe Flat Cost Curve and Why Coupling Is the Real EnemyAdam makes a direct business case for event sourcing and event modeling: Adaptech Group offers fixed-cost contracts and fixes bugs for free. This isn’t charity; it’s a direct consequence of an architecture where new features don’t touch existing code, coupling is managed by design, and the immutable event ledger serves as the single source of truth.Key points:* The “hockey stick” cost curve in traditional software comes from coupling: shared canonical models, CRUD operations that affect multiple consumers, and abstractions that break everything when they change* Event sourcing inverts this by using multiple purpose-built read models that each have exactly what they need, coordinated by an undisputed set of events* Schema migrations effectively disappear because new versions of data and old versions coexist naturally* The biggest conceptual barrier is the industry’s attachment to a single canonical model, an idea sold from academia through inheritance hierarchies that doesn’t mirror how real-world information systems have operated for centuriesAI as the Next Point of No ReturnThe conversation turns to AI, which Adam frames alongside the Commodore 64, the internet, email, Linux, and event sourcing itself as an irreversible “aha moment.” His own turning point was watching ChatGPT generate CSS animations in seconds that would have taken him three hours, and he sees event modeling as the missing link that gives AI the specification quality it needs to generate real systems.Key points:* AI’s impact is comparable to how Google gave us access to everything, but AI gives us the ability to make sense of everything instantly* The bottleneck is shifting left to planning, which is exactly where event modeling lives: providing clear, structured specifications that AI can execute against* Adam demonstrated early success pasting event model screenshots into Cursor’s chat window and getting correct unit tests and implementations on the first try, even with less capable models* The Pandora’s box framing: you can’t uninvent the internet, and you can’t uninvent AI inference; the question is whether your specifications are good enough to benefit from itTwo Books and What’s NextAdam closes with an update on his long-anticipated event modeling book, which is actually two books. Inspired by Eric Evans’ companion booklet to the DDD blue book and Michael Feathers’ reference-pattern format in Working Effectively with Legacy Code, Adam is releasing a concise booklet first, followed by a comprehensive reference book.Key points:* The booklet comes first, designed to be immediately applicable, covering why event modeling exists, its core pieces, and the rules for assembling them* The full book will include the backstory and motivations, plus a library of reference patterns covering the top 90% of common information system scenarios (sign-up flows, payment integrations, checkout carts, pub/sub patterns, and more)* Adam deliberately delayed the book because he never wanted event modeling to require a book to understand, a lesson drawn directly from watching the DDD book’s intimidating thickness reduce its effective adoption* Martin Dilger’s Understanding Eventsourcing already covers event sourcing using event modeling throughout, giving the community a practical resource while the definitive event modeling book takes shapeHard Boiled Software is hosted by Dave Laribee. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://newsletter.nerdnoir.com?utm_medium=podcast&utm_campaign=CTA_1">newsletter.nerdnoir.com</a>

7 total episodes available

Deep-dive analytics for Hard Boiled Software

Frequently asked questions

Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.

What is Hard Boiled Software?: Guest stories and viewpoints from the gritty streets of software engineering. <a href="https://newsletter.nerdnoir.com?utm_medium=podcast">newsletter.nerdnoir.com</a>
How often does this podcast release new episodes?: This podcast updates daily.
Where can I listen to this podcast?: This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
Does this podcast accept guests?: Information about guest appearances is not available.

Legal Disclaimer

Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.

All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.

We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.

While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.

By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.