Maintainable

1. Mark Stringer: Software Costs More Than We Want to Admit

   27 de octubre de 20261 h 8 minEpisodio 231A continuación

   Software is expensive to build, expensive to change, and expensive to keep alive. Yet organizations routinely make plans as though adding another feature or hitting an arbitrary deadline won't affect anything …

   Notas del episodio

   Software is expensive to build, expensive to change, and expensive to keep alive. Yet organizations routinely make plans as though adding another feature or hitting an arbitrary deadline won't affect anything else. Mark Stringer joins Robby to explore why making those trade-offs visible is an essential part of maintaining software.

   Mark describes his approach as "showing people the taxi meter." Instead of asking stakeholders which requirements they suddenly don't want anymore, teams can help them understand what each decision costs and what it does to the other priorities already underway. That becomes particularly important when deadlines enter the picture. Mark has stopped fighting deadlines altogether. The goal is to get useful information from them while doing as little damage as possible. Along the way, Mark references Daniel Kahneman's Thinking, Fast and Slow and the idea that "what you see is all there is."

   The conversation also looks at what happens as software ages. Mark shares the story of handing a UK government system over to another team, including documenting not only the code but the roles people played and the parts of the system they already expected would need replacing. Libraries disappear, tooling changes, companies supporting compilers go out of business, and yesterday's reasonable technical decision becomes tomorrow's maintenance problem. Long-lived software requires accepting that replacement and adaptation are part of the deal.

   Mark also discusses his book, Delivering the Impossible: Successful Ways of Seeing Software Project Management, and why software projects are better understood as bets than guarantees. Using metaphors ranging from biscuit tins to swamps and pirate ships, he explains how teams can mistake descriptions of software for the thing itself, underestimate complexity, and fall into "agreed activity": doing work everyone accepts while ignoring the larger problem approaching on the horizon. When organizations punish people for delivering bad news, eventually the bad news stops arriving.

   Topics

   [00:00:55] What Makes Software Maintainable: Mark explains why maintainability begins with understanding what users are actually trying to accomplish, rather than focusing solely on principles inside the code.

   [00:05:00] Deadlines, Trade-offs, and the Taxi Meter: Robby and Mark discuss why deadlines aren't going away, what stakeholders may unknowingly ask teams to sacrifice, and how to make the cost of competing priorities visible.

   [00:13:20] The Real Cost of Software: Mark calls software's extraordinary expense one of the industry's "dark secrets" and questions whether AI and vibe coding are making software cheaper or simply changing how those costs are presented.

   [00:18:00] Handing Software to the Next Team: Mark shares how his team documented and handed over a UK government system, why cooperating with the incoming team mattered, and how a good exit eventually led to more work.

   [00:28:22] Planning for Software to Age: Mark describes identifying homegrown components and dependencies that future maintainers would need to replace, and why parts of a stack can have surprisingly short half-lives.

   [00:34:32] Delivering the Impossible: Mark explains what led him to write Delivering the Impossible and why he chose to offer different ways of seeing software projects rather than another methodology promising success.

   [00:37:20] Biscuits, Biscuit Tins, and Software: Mark draws on his philosophy background to explain the difference between software and descriptions of software, and why organizations often spend more time dealing with the description than the thing itself.

   [00:47:20] Software Projects Are Swamps: Complex projects contain technical, organizational, regulatory, and human uncertainties that make straightforward input-output thinking unreliable.

   [00:51:53] Projects Are Bets: Mark argues that project success can never be guaranteed. Teams can improve their odds through research, experimentation, and observation, while some decisions can make failure increasingly certain.

   [00:57:00] The Pirate Ship Everyone Can See: Drawing on the work of improvisation teacher Keith Johnstone, Mark introduces "agreed activity," where teams stay busy with accepted work while ignoring an obvious threat. Robby and Mark explore what happens when organizations teach engineers that delivering bad news isn't welcome.

   [01:04:00] Taking Project Management to the Edinburgh Fringe: Mark talks about turning his ideas into live performances, writing Delivering the Impossible, and performing his latest show, You Can Write a Book.

   Thanks to Our Sponsors!

   Undercover CI: Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   Equitybee: Exercising your startup stock options shouldn't mean draining your savings. Equitybee covers your exercise costs and related taxes with non-recourse funding. If the company never exits, you owe nothing. Explore your options at equitybee.com.

   Links & Resources

   • Mark Stringer's website
   • Mark Stringer on LinkedIn
   • Delivering the Impossible: Successful Ways of Seeing Software Project Management by Mark Stringer
   • Thinking, Fast and Slow by Daniel Kahneman
   • Keith Johnstone
   • Edinburgh Festival Fringe

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

2. Gabriela Moreira: When 800 Tests Aren’t Enough

   13 de octubre de 202653 minEpisodio 230A continuación

   A large test suite should make developers feel safer changing software. Gabriela Moreira, CEO of Quint, has recently experienced something quite different: a new codebase grew from roughly 200 tests to 800 with …

   Notas del episodio

   A large test suite should make developers feel safer changing software. Gabriela Moreira, CEO of Quint, has recently experienced something quite different: a new codebase grew from roughly 200 tests to 800 with the help of AI, yet she found herself trusting the suite less and manually verifying behavior more. Gabriela and Robby unpack the difference between having tests and understanding what those tests actually protect, including why she has a particular appreciation for regression tests that preserve the history of real problems.

   That question of understanding leads into Gabriela's work on Quint, an open-source executable specification language influenced by TLA+. Gabriela explains how developers can model behaviors and explore edge cases before those scenarios reach production. Rather than treating formal methods as something reserved for banks and safety-critical systems, she makes the case for using specifications more broadly to reason about concurrency, state changes, multiple users, and other situations where software can behave in more ways than a developer can comfortably keep in their head.

   The conversation also digs into the relationship between specifications and existing test suites. Gabriela describes model-based testing, trace validation, and the challenge of keeping a specification synchronized with the code that actually runs in production. She also shares a Kubernetes example involving the OpenHands team, where modeling a race condition with Quint showed that a proposed fix would still fail in another scenario. The team could explore another solution before waiting for the intermittent production problem to return.

   As AI takes over more implementation and debugging work, Gabriela argues that developers need to strengthen their judgment about how software should behave. She pushes back on workflows where humans are expected to fully describe a solution in a giant Markdown document before handing it to an agent. For Gabriela, some of the useful and enjoyable parts of programming come from experimentation: trying something, seeing what happens, changing your understanding, and trying again. If agents increasingly handle the mechanical work, preserving that ability to explore, evaluate, and make decisions may matter more than simply producing more code.

   Topics & Timestamps

   • [00:00:53] What Makes Software Maintainable? Gabriela starts with trustworthy tests and explains why confidence comes from understanding both the tests and the behavior they protect.
   • [00:03:06] When Hundreds of Tests Still Aren't Reassuring: Gabriela describes a new AI-assisted codebase that quickly grew from around 200 tests to 800, while her confidence in the suite declined.
   • [00:06:00] What Is Quint? Gabriela introduces Quint as an executable specification language and explains how it can be used to model and verify software behavior.
   • [00:08:29] Where Formal Specifications Fit in Everyday Development: Robby asks whether these techniques apply to ordinary web applications, leading to examples involving multiple users, state changes, and edge cases.
   • [00:12:23] Why Build Another Specification Language? Gabriela explains Quint's relationship to TLA+ and why her team wanted to make formal specification more approachable for working programmers.
   • [00:16:15] Who Is Quint Actually For? Gabriela makes the case that reasoning about software behavior isn't limited to developers working on distributed systems or critical infrastructure.
   • [00:18:11] AI Lowers the Barrier to Formal Methods: Gabriela explains how coding agents have changed the cost of learning and writing formal specifications.
   • [00:20:52] Keeping Specifications and Code in Sync: Gabriela walks through model-based testing, trace validation, and the maintenance problems that arise when specifications drift away from implementation.
   • [00:25:00] Who Decides What "Correct" Means? Robby and Gabriela explore the difference between obvious correctness properties and product behaviors that require human context and judgment.
   • [00:31:58] Bridging Academia and Everyday Software Development: Gabriela discusses the divide between programming-language research and industry, and why she wants formal methods to become more accessible.
   • [00:35:22] Catching a Kubernetes Fix Before Shipping It: Gabriela shares how the OpenHands team modeled an intermittent Kubernetes problem and discovered that their first proposed fix wouldn't actually solve every scenario.
   • [00:40:00] What Should We Still Delegate to Humans? The conversation turns to AI development workflows and why Gabriela doesn't want programming to become writing exhaustive instructions for agents.
   • [00:45:25] Human Judgment as a Software Engineering Skill: Gabriela argues that developers who can judge how software should behave may become more valuable as AI takes over more implementation work.
   • [00:47:06] A Small Formal Methods Homework Assignment: Gabriela suggests starting with something familiar, finding the state machine hiding inside it, and modeling it with Quint.
   • [00:50:47] Recommended Reading: Gabriela recommends The Name of the Wind by Patrick Rothfuss.

   Thanks to Our Sponsor!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   Resources & Links

   • Quint 
   • Quint on GitHub
   • Towards a Solution for Cognitive Debt
   • Quint Connect and the Emerald project
   • TLA+
   • OpenHands
   • Gabriela Moreira on LinkedIn
   • Gabriela's interview with Unite.AI
   • The Name of the Wind by Patrick Rothfuss
   • OpenHands Kubernetes Use Case
   • Trying out Quint: 5-min getting started
   • Sign up for Quint Studio

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

3. Matija Šošić: Abstractions Aren’t Going Anywhere

   6 de octubre de 202654 minEpisodio 229A continuación

   What makes software maintainable might have less to do with how clean the code looks and more to do with how well it serves the people responsible for it. Matija Šošić, co-founder and CEO of Wasp, joins Robby …

   Notas del episodio

   What makes software maintainable might have less to do with how clean the code looks and more to do with how well it serves the people responsible for it. Matija Šošić, co-founder and CEO of Wasp, joins Robby to talk about boring and predictable code, resisting unnecessary abstractions, and why understanding the ugly parts of a system matters.

   They trace Wasp's evolution from a custom domain-specific language to TypeScript, why web development keeps cycling between bundling and unbundling, and what framework authors can learn from Rails and Laravel. They also dig into AI-generated code and Matija's argument that cheaper code doesn't eliminate the need for abstractions. If anything, frameworks and their constraints may become even more useful when agents are writing more of the implementation.

   Topics

   [00:00:51] Software Should Serve the People Maintaining It: Matija describes maintainability in terms of whether developers understand their system and feel comfortable working within it.

   [00:02:25] Boring and Predictable Code: Why a little repetition can be healthier than reaching for another abstraction too early.

   [00:05:39] What Is Wasp?: Matija introduces Wasp and the desire for a more cohesive full-stack JavaScript framework.

   [00:07:15] Where the Idea for Wasp Came From: Framework fatigue, constantly changing JavaScript stacks, and the desire to stop reinventing the same decisions from project to project.

   [00:13:11] Building a Custom Language: Matija explains why Wasp started with its own DSL and the goal of separating an application's specification from its underlying technology.

   [00:17:36] The Economics of an Open Source Framework: Robby and Matija discuss Y Combinator, venture funding, distribution, and how a framework can eventually become a business.

   [00:24:05] Becoming "Abstraction Curators": How the Wasp team decides what deserves an abstraction and why they try not to invent solutions simply for the sake of being different.

   [00:31:03] Do We Still Need Abstractions When AI Writes Code?: Why Matija believes agents benefit from frameworks, conventions, and guardrails rather than making them obsolete.

   [00:36:29] Moving From a Custom DSL to TypeScript: Why Wasp's language became an adoption barrier and how the team preserved the underlying idea while moving to familiar syntax.

   [00:39:47] Why Is Web Development Still So Complicated?: Matija distinguishes domain complexity from implementation complexity and explains the recurring cycle of bundling and unbundling.

   [00:43:36] Are We Entering Another Bundling Era?: Robby and Matija explore why technologies mature into foundational layers while attention moves toward the next abstraction.

   [00:47:14] Finding Something Solid Amid the AI Noise: Matija discusses reevaluating assumptions about AI while holding onto principles that aren't tied to a particular tool.

   [00:50:51] Don't Bet Your Career on React: Why Matija thinks developers should invest in software engineering fundamentals rather than tying their expertise too closely to today's frameworks.

   Thanks to Our Sponsor!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   Links & Resources

   • Wasp
   • Wasp on GitHub
   • A New Language for Web Dev Was a Mistake
   • Matija Šošić on X
   • Matija Šošić on LinkedIn
   • Zen and the Art of Motorcycle Maintenance
   • Ruby on Rails
   • Laravel
   • Prisma

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

4. José Valim: Designing a Language You Can Maintain for Decades

   29 de septiembre de 202654 minEpisodio 228A continuación

   What does maintainability look like when the software you’re responsible for is a programming language? José Valim creator of Elixir and founder of Dashbit, joins Robby to talk about software that can “fit in …

   Notas del episodio

   What does maintainability look like when the software you’re responsible for is a programming language? José Valim creator of Elixir and founder of Dashbit, joins Robby to talk about software that can “fit in your head,” the importance of clear boundaries, and why maintaining a language requires a different level of restraint than maintaining an application.

   José traces Elixir’s origins back to his time on the Rails Core team and a concurrency bug that sent him looking for different approaches to software. That journey led through functional programming to Erlang and the BEAM, where he found ideas around immutability, concurrency, and distributed systems that reshaped how he thought about software. He explains why Elixir was designed to be extensible, allowing communities to build things like Phoenix and Numerical Elixir without continually expanding the language itself.

   Robby and José also look at what AI is changing for maintainers. José explains how Tidewave gives coding agents access to context that frameworks already provide to developers, why documentation and good error messages have become unexpectedly valuable to agents, and how AI-generated contributions are changing open-source collaboration. They also explore whether coding agents might change the old calculus around dependencies, SDKs, and choosing a programming language.

   Topics and Timestamps

   • [00:00:53] What Makes Software Maintainable: José compares well-maintained software to good conference Wi-Fi and explains why he values software whose boundaries and moving parts can fit in his head.
   • [00:03:20] Maintaining a Programming Language: How responsibility changes when thousands of applications depend on the software you maintain, and why language designers have to minimize churn for users.
   • [00:10:51] The Origins of Elixir: José tells the story of the Rails concurrency bug that changed his career and sent him exploring functional programming, Erlang, and distributed systems.
   • [00:17:00] Removing the Root Cause: Why José distinguishes between layering a solution over a problem and designing software so the underlying problem disappears.
   • [00:20:47] Designing Elixir to Be Extensible: Why José resisted making Elixir a web-specific language and instead focused on giving developers the building blocks to extend it into new domains.
   • [00:25:42] Restraint and the Elixir Ecosystem: José explains why much of his work moved away from changing the language itself and toward helping communities build on top of it.
   • [00:28:21] Giving Coding Agents Better Context with Tidewave: How Tidewave connects Rails and Phoenix applications with coding agents and exposes information developers already rely on.
   • [00:33:20] Designing for Humans in the Age of AI: Why José believes programming languages should continue optimizing for humans, and how features that help humans often help agents too.
   • [00:36:40] Documentation as Infrastructure: How Elixir’s long-standing investment in first-class documentation, HexDocs, Markdown, and searchable package documentation has translated well to AI-assisted development.
   • [00:41:40] AI and Open-Source Maintenance: José describes the increase in AI-assisted contributions and why AI-generated responses can disrupt the human relationship between contributors and maintainers.
   • [00:46:22] Rethinking Dependencies and Language Choice: Robby and José consider whether AI makes it easier to bring ideas across ecosystems instead of rewriting applications or depending on large SDKs.

   Thanks to Our Sponsors!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   Mailtrap is a modern email delivery platform built for developers. Native SDKs, a secure Email API and SMTP, and a free tier with 4,000 emails a month. When you need help, you'll reach real people on 24/7 support, not an AI chatbot. Try Mailtrap for free!

   Resources and Links

   • Elixir
   • Dashbit
   • Tidewave
   • Phoenix Framework
   • Erlang
   • Hex
   • HexDocs
   • Numerical Elixir
   • Nx
   • Foundation by Isaac Asimov
   • Dune by Frank Herbert

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

5. John Athayde: Maintaining the User Side of Software

   8 de septiembre de 20261 h 22 minEpisodio 227A continuación

   Software maintainability is often discussed through the codebase, but users experience years of accumulated decisions through the interface. John Athayde of Meticulous joins Robby to examine maintainability …

   Notas del episodio

   Software maintainability is often discussed through the codebase, but users experience years of accumulated decisions through the interface. John Athayde of Meticulous joins Robby to examine maintainability from the front-end and product-design side, starting with documentation and the context it preserves for future teams.

   John describes how older applications accumulate multiple UI libraries, generations of CSS, inconsistent components, and different interaction patterns. Improving these systems does not always require a redesign. Sometimes the more valuable work is removing dependencies the browser no longer needs, consolidating patterns, and understanding which unusual workflows users still depend on. They also explore how design systems can become part of a maintenance strategy, provided teams treat them as products that require governance and restraint.

   Later, Robby and John turn to AI. John is using AI tooling to audit applications, find repeated patterns, remove old dependencies, expand tests, and reconstruct requirements from existing code. These tools can make software archaeology and large-scale changes much faster, but speed does not replace judgment. The challenge is understanding what should change, what needs to remain, and whether today's faster implementation is creating software tomorrow's team can still maintain.

   Topics

   • [00:02:00] Documentation as a Sign of Maintainability: Why documentation and evidence of ongoing care matter when entering an existing codebase.
   • [00:07:02] Maintainability From the User's Side: Dated interfaces, usability, and replacing old dependencies with modern browser capabilities.
   • [00:11:22] Making the Case for Cleanup: Connecting technical cleanup to development speed and the ability to ship future features.
   • [00:13:27] Bringing Coherence to Operational Software: How products accumulate different interfaces and patterns through years of development and acquisitions.
   • [00:19:14] Finding the Why: Discovering how software is actually used before deciding what should change or disappear.
   • [00:24:44] Knowing When to Remove Things: Product ownership, sunsetting features, and the organizational politics of taking functionality away.
   • [00:34:05] Why Designers Should Understand Code: How technical fluency helps designers and UX awareness helps developers.
   • [00:39:00] Choosing Tools in Service of the Product: Balancing new frameworks and experimentation against what a team can maintain.
   • [00:47:19] Design Systems as Maintainable Products: Tokens, components, governance, and auditing years of accumulated UI decisions.
   • [00:51:39] Using AI for Front-End Archaeology: Applying AI and static analysis to find patterns, remove dependencies, and investigate old applications.
   • [01:04:00] Rewrite or Refactor in the AI Era?: How tests, captured requirements, and AI-assisted development may change the economics of rewrites.
   • [01:14:20] Where AI Still Needs Human Judgment: Why faster implementation does not eliminate difficult product and engineering decisions.

   Thanks to Our Sponsors!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   Mailtrap is a modern email delivery platform built for developers. Native SDKs, a secure Email API and SMTP, and a free tier with 4,000 emails a month. When you need help, you'll reach real people on 24/7 support, not an AI chatbot. Try Mailtrap for free!

   Links & Resources

   • John Athayde
   • Meticulous
   • John Athayde on LinkedIn
   • John Athayde on Bluesky
   • John Athayde on X
   • John Athayde on Ruby Social
   • The Timeless Way of Building by Christopher Alexander
   • A Pattern Language by Christopher Alexander, Sara Ishikawa, and Murray Silverstein
   • The Phoenix Architecture by Chad Fowler
   • Ruby on Rails
   • Axe-core
   • Herb, HTML+ERB tooling by Marco Roth

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

6. Kristin Isaac: The Customer Doesn’t Care About Your Technical Debt

   1 de septiembre de 202654 minEpisodio 226A continuación

   Technical debt rarely arrives in a support ticket labeled “technical debt.” Customers experience something simpler: the product is slow, unreliable, or the same problem keeps coming back. Kristin Isaac …

   Notas del episodio

   Technical debt rarely arrives in a support ticket labeled “technical debt.” Customers experience something simpler: the product is slow, unreliable, or the same problem keeps coming back. Kristin Isaac, Co-Founder and CEO of Strudel, joins Robby to look at software maintainability from the customer and product side of the organization. Kristin shares how her background in customer success, sales, and support shaped the way she thinks about reliability and why engineering teams often lack the business context surrounding the problems they’re being asked to solve.

   That disconnect becomes especially important when engineers need to advocate for work customers may never directly see. Kristin and Robby explore why talking about technical debt alone often fails to persuade business leaders, and how engineers can instead connect maintenance work to customer experience, renewals, revenue, reliability, and risk. They also discuss the danger of letting the loudest customer determine priorities, the tension between urgent roadmap work and important foundational work, and why engineers shouldn’t quietly absorb the trade-offs that come with shipping faster. Kristin argues that better storytelling, shared metrics, and stronger relationships with customer-facing teams can help engineering make a much stronger case.

   The conversation also turns to AI and the growing gap between generating software and understanding it. Robby and Kristin consider what happens when engineers increasingly ask AI for help instead of their teammates, and what that might mean for collaboration, onboarding, and learning. Rather than keeping that experimentation inside engineering, Kristin sees an opportunity for engineers to become educators across the organization… helping colleagues understand where AI works, where it falls short, and how teams can experiment with it together.

   Episode Highlights

   [00:00:49] Measuring Well-Maintained Software: Kristin shares practical measures around alert volume, detection time, recovery time, and confidence in frequent deployments.

   [00:02:26] What Strudel Does: Kristin explains Strudel’s focus on bringing engineering, support, customer, and business context together around technical customer issues.

   [00:07:35] What Customers Actually Experience: Robby and Kristin connect technical debt to the problems customers notice, including slow, unreliable, and broken software.

   [00:12:39] Prioritizing With Business Context: They explore competing incentives across engineering, product, sales, support, and customer success, including the danger of relying on the “squeaky wheel.”

   [00:21:14] Different Teams, Different Versions of the Problem: Kristin explains why no single department necessarily has the complete picture and why shared context matters.

   [00:23:29] Who Owns Reliability?: Robby and Kristin consider where responsibility for reliability sits across engineering, product, and the broader organization.

   [00:24:32] Making the Case for Technical Debt: Kristin explains why technical debt is easier to ignore when engineers can’t connect it to measurable customer or business impact.

   [00:26:21] Advocating for Invisible Maintenance Work: The conversation turns to foundational improvements, the tension between urgent and important work, and partnering with customer-facing teams to build a stronger case.

   [00:33:25] Engineers as Storytellers: Kristin argues that engineers can become more effective advocates by learning how to communicate technical concerns in terms the rest of the business understands.

   [00:34:54] AI and the Understanding Gap: Robby and Kristin discuss whether software is becoming faster to generate than it is to understand and maintain.

   [00:37:20] What Happens When Engineers Stop Asking Each Other?: They explore AI’s potential effects on collaboration, learning, onboarding, and the social dynamics of engineering teams.

   [00:46:20] Engineers as AI Educators: Kristin makes the case for engineers sharing their AI experiments with product, sales, marketing, and customer-facing teams instead of keeping that knowledge inside engineering.

   Thanks to Our Sponsors!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   [Mailtrap]Mailtrap is a modern email delivery platform built for developers. Native SDKs, a secure Email API and SMTP, and a free tier with 4,000 emails a month. When you need help, you'll reach real people on 24/7 support, not an AI chatbot. Try Mailtrap for free!

   Resources & Links

   • Strudel
   • Kristin Isaac on LinkedIn
   • Strudel on LinkedIn
   • Empire of AI by Karen Hao
   • Fablehaven series by Brandon Mull

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

7. David Hayes: Boring Software, Clear Incentives, and Better Checklists

   18 de agosto de 202655 minEpisodio 225A continuación

   Drawing from his experience at PagerDuty, Sentry, and now FusionAuth, he joins Robby to explore what happens when software becomes trusted infrastructure. Their conversation touches on API design, naming …

   Notas del episodio

   Drawing from his experience at PagerDuty, Sentry, and now FusionAuth, he joins Robby to explore what happens when software becomes trusted infrastructure. Their conversation touches on API design, naming things, product management, self-hosted software, and why customers rarely upgrade as quickly as we’d like them to.

   They also discuss why “boring” software is often the most successful, how engineering teams can better communicate technical debt by connecting it to customer outcomes, and why estimates and scope creep are often influenced as much by human psychology as technical complexity. David shares lessons from supporting long-lived authentication systems and explains why stability, compatibility, and predictable upgrades matter more than constantly shipping flashy new features.

   The conversation takes an unexpected turn into naval history, where David draws parallels between successful fleets and successful software teams. Clear incentives, strong communication, and dependable checklists consistently outperform heroics. As AI becomes part of the software development process, those lessons feel even more relevant. Teams that make expectations explicit, align around customer outcomes, and invest in reliable processes will be better positioned for whatever comes next.

   Episode Highlights

   [00:00:50] What Makes Software Truly Maintainable: David explains why fitness for purpose is at the heart of maintainable software.

   [00:04:32] API Design Decisions That Last for Years: David shares lessons from PagerDuty about naming, breaking changes, and the long-term consequences of API decisions.

   [00:10:44] What FusionAuth Is and Why Authentication Is Different: David explains FusionAuth and why authentication is a problem many teams are better off not solving themselves.

   [00:16:57] The Realities of Maintaining Self-Hosted Software: Supporting self-hosted deployments means balancing upgrades, compatibility, security, and customer control.

   [00:24:49] Why Customers Rarely Upgrade the Way Product Teams Expect: David explains why customers often settle into a product’s existing capabilities and may not rush to adopt new features.

   [00:27:37] What “Boring Software” Really Means: David makes the case that successful software should focus on making users successful rather than giving teams opportunities to build what they find exciting.

   [00:29:56] Connecting Technical Debt to Business Outcomes: David discusses why engineering teams need to connect technical debt to customer outcomes and broader business needs.

   [00:39:22] Estimates, Optimism, and Scope Creep: David explores how estimates can become persuasion tools and how optimism can unintentionally expand project scope.

   [00:43:15] Naval Warfare Lessons for Software Teams: David draws unexpected parallels between naval history, incentives, communication, and software development.

   [00:48:29] Alignment, Checklists, and Operational Excellence: David explains why aligned teams with reliable processes consistently outperform teams that rely on individual heroics.

   [00:51:21] AI, Explicit Instructions, and the Future of Software Development: David discusses how AI is changing the skills, expectations, and checklists developers need to work effectively.

   [00:53:29] Where to Learn More About FusionAuth: David shares where listeners can learn more about FusionAuth and its work around authentication and compliance.

   Thanks to Our Sponsors!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   [Mailtrap]Mailtrap is a modern email delivery platform built for developers. Native SDKs, a secure Email API and SMTP, and a free tier with 4,000 emails a month. When you need help, you'll reach real people on 24/7 support, not an AI chatbot. Try Mailtrap for free!

   Resources & Links

   • FusionAuth
   • FusionAuth Blog
   • PagerDuty
   • Sentry
   • curl

   Book Recommendations

   • Castles of Steel: Britain, Germany, and the Winning of the Great War at Sea by Robert K. Massie
   • The Last Stand of the Tin Can Sailors: The Extraordinary World War II Story of the U.S. Navy's Finest Hour by James D. Hornfischer

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

8. Diana Pfeil: Building Confidence in Probabilistic Systems

   4 de agosto de 202649 minEpisodio 224A continuación

   Machine learning systems can degrade even when the underlying code has not changed. Diana Pfeil of Sunbeam Consulting joins Robby Russell on Maintainable to explain how changing data, model behavior, and …

   Notas del episodio

   Machine learning systems can degrade even when the underlying code has not changed. Diana Pfeil of Sunbeam Consulting joins Robby Russell on Maintainable to explain how changing data, model behavior, and non-deterministic outputs create a different kind of maintenance challenge.

   Rather than asking whether a system is simply correct or incorrect, teams need reliable ways to measure confidence in its behavior.

   Diana introduces evals as a way to test AI-generated outputs that may be phrased differently each time. She and Robby discuss using LLMs to judge other LLM outputs, reviewing production traces, sampling unusual cases, protecting sensitive data, and keeping humans involved when automated checks cannot provide enough confidence.

   They also explore how prompts should be versioned and tested against representative examples.

   The conversation turns to the operational costs that come with AI features. Model providers can deprecate dependencies quickly, prompts may behave differently after an upgrade, and teams must continue monitoring systems that might once have been considered finished.

   Diana encourages organizations to ask what can now be automated, how accurate the result needs to be, and whether the benefit justifies the additional maintenance work.

   Diana also makes the case for starting with the simplest model or deterministic process that can solve the problem. Teams can add complexity once the baseline proves insufficient, but designing around imagined future requirements often creates the wrong system.

   Her advice for engineers trying to introduce AI internally is equally direct: build a small prototype that solves a real problem, then let the result make the case.

   Episode Highlights

   [00:00:50] Maintaining Probabilistic Software: Diana explains why maintaining AI systems involves the code, changing data, model behavior, and confidence in the output.

   [00:02:35] What Are Evals?: Robby asks how teams test AI-generated results when the correct response may be worded differently each time.

   [00:04:38] Using an LLM as a Judge: Diana describes using one model to evaluate another and why the judge must be calibrated against human decisions.

   [00:06:39] Monitoring AI in Production: Diana introduces human review, traces, observability, and production sampling.

   [00:08:44] Recognizing Input Drift: A meeting-notes example shows how changing inputs can degrade an otherwise unchanged system.

   [00:12:06] Maintaining Models and Prompts: Diana outlines the code, model, prompt, and data-pipeline changes teams may need to make.

   [00:14:24] Versioning and Testing Prompts: Robby asks how prompt experimentation fits into source control and repeatable testing.

   [00:18:32] Building Confidence in a Black Box: Diana explains how evals and production reviews help teams avoid regressions.

   [00:21:16] Diana’s Machine Learning Background: Diana shares her path from recommendation systems at Amazon to startup leadership and consulting.

   [00:22:26] How Sunbeam Consulting Helps Teams: Diana describes advising leaders on AI strategy and helping teams build machine learning products.

   [00:24:28] Finding Useful Automation Opportunities: Diana explains how teams can identify previously unstructured work that may now be practical to automate.

   [00:27:40] The Cost of Automated Decisions: Robby and Diana compare human error with the oversight and infrastructure required by AI systems.

   [00:30:14] AI Is Not Free to Maintain: Diana discusses model deprecations, vendor dependencies, and the ongoing support required after launch.

   [00:36:45] Keeping Up With Rapidly Changing Tools: Diana explains why teams need room to experiment without constantly disrupting established workflows.

   [00:38:49] Why Simpler Models Often Win: Diana makes the case for starting with a baseline before introducing more sophisticated approaches.

   [00:45:18] Selling an AI Idea Without the Buzzwords: Diana recommends building a useful prototype and allowing the result to make the case.

   [00:46:30] The Inner Game of Tennis: Diana recommends W. Timothy Gallwey’s book about learning, judgment, and performance.

   Resources Mentioned

   • Sunbeam Consulting
   • Diana Pfeil on LinkedIn
   • Pydantic
   • Amazon Bedrock Guardrails
   • Claude Code
   • Cursor
   • OpenAI Codex
   • The Inner Game of Tennis by W. Timothy Gallwey

   Thanks to Our Sponsors!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   Mailtrap is a modern email delivery platform built for developers. Native SDKs, a secure Email API and SMTP, and a free tier with 4,000 emails a month. When you need help, you'll reach real people on 24/7 support, not an AI chatbot. Try Mailtrap for free!

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

9. Chris Coyier: The Long Game of Maintaining CodePen

   16 de junio de 202655 minEpisodio 223A continuación

   What does it take to keep a product healthy after more than 15 years of continuous evolution? In this episode, Robby Russell talks with Chris Coyier, co-founder of CodePen, about the long game of maintaining …

   Notas del episodio

   What does it take to keep a product healthy after more than 15 years of continuous evolution?

   In this episode, Robby Russell talks with Chris Coyier, co-founder of CodePen, about the long game of maintaining software. Chris shares how CodePen has evolved over time, the trade-offs involved in migrating parts of the platform from Rails to Go, and the challenges of balancing maintenance work with the desire to build what's next.

   They also explore the human side of maintainability, the role of technical debt in shaping priorities, and why small teams often have to make very intentional decisions about where to invest their limited time and attention.

   Whether you're maintaining a side project, stewarding a legacy application, or helping a team navigate change, this conversation offers practical insights into building software that lasts.

   Key Topics

   • Defining what "well-maintained software" really means
   • Why maintainability is often more of a people problem than a code problem
   • The origin story of CodePen
   • Supporting a product that has evolved over 15 years
   • Balancing maintenance work with product evolution
   • Gradually migrating from Rails to Go
   • Using GraphQL across multiple implementations
   • Technical debt and its many interpretations
   • Team size, communication overhead, and organizational design
   • Simplifying software by embracing browser capabilities

   Links & Resources

   • ChrisCoyier.net
   • Chris Coyier on Bluesky
   • CodePen
   • ShopTalk Show
   • CSS-Tricks

   Book Recommendation

   Understanding Comics: The Invisible Art (Goodreads) by Scott McCloud

   Thanks to Our Sponsors!

   Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

   Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out!

   Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

10. Sally Lait: Confidence Is the Real Metric

    5 de mayo de 202656 minEpisodio 222A continuación

    Sally Lait joins Robby Russell on Maintainable to explore software maintainability through a different lens… not just code quality, but how teams work together over time. Sally is a fractional technology leader …

    Notas del episodio

    Sally Lait joins Robby Russell on Maintainable to explore software maintainability through a different lens… not just code quality, but how teams work together over time.

    Sally is a fractional technology leader and advisor with more than two decades in the industry. You can follow her on LinkedIn or Mastodon.

    They start with a familiar question: what makes software well maintained? Structure and standards matter, but Sally shifts the focus to signals around the edges… documentation, onboarding speed, knowledge sharing, and especially how confident people feel making changes.

    That confidence becomes the thread throughout the conversation.

    Teams with high confidence move faster and adapt more easily. Teams with low confidence hesitate, avoid parts of the system, and struggle to make progress… regardless of what the code looks like.

    Robby and Sally also dig into why maintenance work often struggles to get traction. It rarely speaks for itself. Leaders need to connect it to outcomes the business already cares about… risk, hiring, delivery speed, and long-term sustainability.

    Sally references a LeadDev panel she moderated on why maintenance still feels “stuck in 2015”: Why Software Maintenance Is Stuck in 2015.

    They also discuss modernizing legacy systems and moving away from long-standing in-house software… work that is rarely just technical. It requires trust, clear communication, and navigating the emotional attachment teams have to what they’ve built.

    The episode closes with advice for engineers joining older codebases: stay curious, build relationships early, and use onboarding gaps as opportunities to improve things for the next person.

    Episode Highlights

    [00:01:02] What Makes Software Maintainable: Technical quality matters, but cultural signals often tell the deeper story.

    [00:05:45] Why Progress Still Feels Slow: Even with improvements, teams can feel stuck due to perception gaps.

    [00:07:30] Communicating Small Wins: Lack of visibility into incremental progress impacts morale and confidence.

    [00:12:40] Influencing Without Manipulating: Maintenance work needs to be framed in business terms.

    [00:16:00] Technical Debt as a Hiring Problem: Outdated systems affect recruiting and retention.

    [00:20:22] Modernizing a Siloed System: Unlocking legacy data required both technical and organizational change.

    [00:26:55] Building Trust for Change: Surprise proposals fail… alignment takes time.

    [00:32:39] Letting Go of “Our Baby”: Replacing systems involves emotional and cultural dynamics.

    [00:46:25] Joining an Older Codebase: Practical advice for onboarding and building confidence quickly.

    Resources Mentioned

    • Sally Lait
    • Sally Lait on LinkedIn
    • Sally Lait on Mastodon
    • Why Software Maintenance Is Stuck in 2015 (LeadDev Panel)
    • Lara Hogan
    • The Murderbot Diaries by Martha Wells
    • Death of the Author by Nnedi Okorafor
    • Sally’s Reading & Reviews Site

    Thanks to Our Sponsors!

    Your test coverage says 90%, but that might be misleading. Undercover CI looks at your Ruby pull requests and shows you which parts of your changes weren't tested- not just overall coverage, but what changed and what got missed, down to the method level. Visit undercover-ci.com and use code MAINTAINABLE for 15% off your first billing cycle. Free for public repos. Private repos with unlimited users also available.

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

11. Rein Henrichs: The Real Work of Maintenance Happens Before You Touch the Code

    14 de abril de 202655 minEpisodio 221A continuación

    Software maintenance is often framed as a technical problem. Refactoring code, fixing bugs, or upgrading dependencies. In this conversation, Robby Russell talks with Rein Henrichs about a different lens, one …

    Notas del episodio

    Software maintenance is often framed as a technical problem. Refactoring code, fixing bugs, or upgrading dependencies. In this conversation, Robby Russell talks with Rein Henrichs about a different lens, one centered on understanding.

    Rein is a Principal Software Engineer at Procore, where he works within a large, long-lived system used across the construction industry. Rather than focusing on tooling, Rein emphasizes that well-maintained software is software that makes sense to the people maintaining it.

    To explain this, Rein introduces the idea of the line of representation, drawing on the work of Richard Cook. Engineers do not interact directly with systems. They rely on representations such as logs, dashboards, and code. These are approximations, not reality, echoing ideas from Plato’s Allegory of the Cave.

    When those representations break down, teams lose shared understanding, what Rein describes as “common ground.” This often shows up as weak signals. Subtle indicators that something is not quite right. They are easy to ignore, but over time they lead to confusion and slower decision-making.

    Incidents make this especially visible. Rein explains how teams build alignment under pressure, highlighting that the role of an incident commander is coordination, not control. Clear communication matters as much as technical correctness.

    The conversation also explores how large systems behave in practice. They rarely fail completely. Instead, they degrade in multiple ways at once. While SLOs can help teams respond to customer-facing issues, they do not capture internal clarity or alignment.

    Rein references W. Edwards Deming to highlight a common trap. Not everything that matters can be measured. High-performing teams often rely on judgment, experience, and shared context.

    Toward the end, Rein connects these ideas to The Field Guide to Understanding Human Error by Sidney Dekker, challenging the idea that incidents are simply caused by mistakes. Instead, they emerge from the same behaviors that usually lead to success, just under different conditions.

    For teams working in complex systems, the takeaway is straightforward. Maintaining software depends on maintaining understanding.

    Links & Resources

    • Procore
    • Rein Henrichs on LinkedIn

    Concepts & References

    • How Complex Systems Fail – Richard Cook
    • The Field Guide to Understanding Human Error – Sidney Dekker
    • W. Edwards Deming
    • Gerald Weinberg – Secrets of Consulting

    Referenced in this Conversation

    • Kent Beck: You’re Ignoring Optionality and Paying for It
    • Charity Majors: Deploys Are Just the Beginning
    • Heidi Helfand: The Art and Wisdom of Changing Teams

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

12. Russ Olsen: The Hidden Cost of Forgetting Why the Code Looks Like That

    31 de marzo de 202655 minEpisodio 220A continuación

    Software doesn’t become hard to maintain only because the code is messy. It often becomes hard to maintain because the reasoning behind it disappears. In this episode of Maintainable, Robby Russell talks with …

    Notas del episodio

    Software doesn’t become hard to maintain only because the code is messy. It often becomes hard to maintain because the reasoning behind it disappears.

    In this episode of Maintainable, Robby Russell talks with Russ Olsen about trade-offs, legacy systems, and why maintainability depends on context more than dogma. Russ brings decades of experience across very different kinds of systems, each with its own definition of what “maintainable” actually means.

    A central theme is that software must be understandable to the people maintaining it. Teams tend to document implementation details well, but often fail to capture system-level intent and the trade-offs behind major decisions. Russ makes the case for preserving that thinking, including the alternatives that were rejected, so future maintainers don’t have to rediscover it the hard way.

    The conversation also touches on Russ’s book Eloquent Ruby, Second Edition. Rather than teaching syntax, the book focuses on how Ruby is actually used in practice and why common patterns exist. That leads into a discussion about where elegance improves maintainability, and where it turns into unnecessary cleverness.

    From there, the episode shifts into the realities of working in legacy systems. Russ explains how teams develop pessimism over time, often accepting flawed assumptions about how their systems behave. In some cases, major issues turn out to be far simpler than expected. The challenge is that teams stop looking.

    Robby and Russ also discuss the value of fresh perspective. New engineers or outside contributors can surface assumptions that longtime maintainers overlook. Russ suggests finding “pinch points” in a system as a practical way to understand behavior without needing to fully untangle everything at once.

    Later, the conversation explores developer quality of life. Long build and deploy cycles create daily friction that teams often underestimate. These slow feedback loops quietly degrade productivity and morale over time.

    The episode also tackles rewrites. Russ warns that teams frequently underestimate how much knowledge is embedded in existing systems. Code that looks questionable may reflect constraints no one documented. In practice, most successful rewrites happen incrementally, not all at once.

    The conversation wraps with a reminder that software development is fundamentally a social process. Russ argues that engineers undervalue storytelling, even though it’s one of the most effective ways to connect technical work to real human outcomes.

    Episode Highlights

    • [00:00:40] Defining maintainability: Why context matters more than a universal standard
    • [00:02:01] Beyond code comments: Documenting system intent and trade-offs
    • [00:08:14] Who Eloquent Ruby is for: Understanding how Ruby is used in practice
    • [00:16:21] Elegance vs. cleverness: Where maintainability starts to erode
    • [00:23:18] Legacy pessimism: Why teams stop questioning assumptions
    • [00:29:25] Pinch points: A practical way to understand complex systems
    • [00:32:05] Developer experience: The hidden cost of slow feedback loops
    • [00:38:26] Rewrites: Why they fail and what teams overlook
    • [00:44:00] Storytelling: Connecting technical work to real-world impact

    Resources Mentioned

    • Russ Olsen on LinkedIn
    • Eloquent Ruby, Second Edition
    • Getting Clojure
    • Zen and the Art of Motorcycle Maintenance
    • A History of Western Philosophy

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

13. Joel Oliveira: Predictability Is a Maintainability Feature

    17 de marzo de 20261 h 1 minEpisodio 219A continuación

    Long-lived software systems rarely stay tidy. Over time they accumulate decisions, workarounds, and layers of history that can make even simple changes feel risky. For engineers responsible for maintaining …

    Notas del episodio

    Long-lived software systems rarely stay tidy. Over time they accumulate decisions, workarounds, and layers of history that can make even simple changes feel risky. For engineers responsible for maintaining those systems, the challenge often becomes less about writing new code and more about understanding what already exists.

    In this episode of Maintainable, Robby Russell speaks with Joel Oliveira, Engineering Manager at ezCater, about what helps software remain understandable and adaptable as it evolves.

    Joel starts with a principle that often gets overlooked: predictability. When patterns are consistent and code is organized in familiar ways, engineers can navigate a codebase with confidence. Frameworks like Ruby on Rails reinforce this by encouraging shared conventions, making it easier for developers to orient themselves when working in a new application.

    The conversation also explores how common metrics can be misleading. Test coverage is often treated as a proxy for quality, but Joel explains that it can create a false sense of confidence. Instead, he values testing most as a thinking tool. Practices like test-driven development can help engineers clarify interfaces and better understand the problem before committing to an implementation.

    Joel also shares a story from ezCater about replacing an aging image-cropping service that had become difficult to maintain and required frequent restarts due to a memory leak. Rather than patch the system again, the team introduced ImageProxy, an open source image processing tool created by Evil Martians.

    Because the image URLs flowed through a single object in their GraphQL layer, the team could introduce an adapter and gradually route traffic to the new service using feature flags. This allowed them to migrate safely and incrementally instead of relying on a risky “big bang” change.

    Robby and Joel also discuss how engineers’ perspectives shift over time. Early in a career it is easy to look at legacy code and label it as bad. Joel now sees older systems as layers of decisions shaped by real constraints. Approaching them with empathy makes it easier to improve them thoughtfully.

    The episode closes with advice for engineers maintaining complex systems: frame problems as opportunities. By documenting impact and proposing incremental improvements, teams can steadily move their software toward a healthier future.

    Maintainable software rarely comes from one heroic refactor. More often, it’s the result of many small improvements made by teams who understand their systems and care about how they evolve.

    Episode Highlights

    00:02:18 – Predictability as a Maintainability Feature
    Joel explains why predictable patterns and conventions make large codebases easier to navigate.

    00:07:41 – When Test Coverage Misleads
    Why high coverage can give a false sense of quality.

    00:12:05 – Consulting vs. Product Engineering
    How switching environments shaped Joel’s approach to code.

    00:16:32 – Replacing a Legacy Image Service
    ezCater’s migration away from a failing Node-based image service.

    00:21:14 – Migrating with Adapters and Feature Flags
    How the team gradually moved traffic to ImageProxy.

    00:26:03 – Developing Empathy for Legacy Code
    Why older systems deserve understanding, not blame.

    00:30:47 – The Shift to Engineering Management
    Joel reflects on moving from IC work to leading teams.

    00:34:52 – Advice for Improving Complex Systems
    Small, consistent improvements matter more than big rewrites.

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Links / References

    • Joel Oliveira — LinkedIn
    • Joel Oliveira — Website
    • Joel Oliveira — Mastodon (@jayroh)
    • ezCater
    • ImageProxy

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

14. Lucas Roesler: The Fast Feedback Loop Advantage

    3 de febrero de 202654 minEpisodio 218A continuación

    Maintaining software over time rarely fails because of one bad decision. It fails because teams stop getting clear signals… and start guessing.In this episode, Robby talks with Lucas Roesler, Managing Partner …

    Notas del episodio

    Maintaining software over time rarely fails because of one bad decision. It fails because teams stop getting clear signals… and start guessing.

    In this episode, Robby talks with Lucas Roesler, Managing Partner and CTO at Contiamo. Lucas joins from Berlin to unpack what maintainability looks like in practice when you are dealing with real constraints… limited context, missing documentation, and systems that resist understanding.

    A big through-line is feedback. Lucas argues that long-lived systems become easier to change when they provide fast, trustworthy signals about what they are doing. That can look like tests that validate assumptions, tooling that makes runtime behavior visible, and a habit of designing for observability instead of treating it as a bolt-on.

    The conversation also gets concrete. Lucas shares a modernization effort built on a decade-old tangle of database logic… views, triggers, stored procedures, and materializations… created by a single engineer who was no longer around. With little documentation to lean on, the team had to build their own approach to “reading” the system and mapping dependencies before they could safely change anything.

    If you maintain software that has outlived its original authors, this is a grounded look at what helps teams move from uncertainty to confidence… without heroics, and without rewriting for sport.

    Episode Highlights

    • [00:00:46] What well-maintained software has in common: Robby asks Lucas what traits show up in systems that hold together over time.
    • [00:03:25] Readability at runtime: Lucas connects maintainability to observability and understanding what a system actually did.
    • [00:16:08] Writing the system down as code: Infrastructure, CI/CD, and processes as code to reduce guesswork and improve reproducibility.
    • [00:17:42] How client engagements work in practice: How Lucas’ team collaborates with internal engineering teams and hands work off.
    • [00:25:21] The “rat’s nest” modernization story: Untangling a legacy data system with years of database logic and missing context.
    • [00:29:40] Making data work testable: Why testability matters even when the “code” is SQL and pipelines.
    • [00:34:59] Pivot back to feedback loops: Robby steers into why logs, metrics, and tracing shape better decision-making.
    • [00:35:20] Why teams avoid metrics and tracing: The organizational friction of adding “one more component.”
    • [00:42:59] Local observability with Grafana: Using visual feedback to spot waterfalls, sequential work, and hidden coupling.
    • [00:50:00] Non-technical book recommendations: What Lucas reads and recommends outside of software.

    Links & ReferencesGuest and Company

    • Lucas Roesler: https://lucasroesler.com/
    • Contiamo: https://contiamo.com/

    Social

    • Mastodon: https://floss.social/@theaxer
    • Bluesky: https://bsky.app/profile/theaxer.bsky.social

    Books Mentioned

    • The Wheel of Time (Robert Jordan): https://en.wikipedia.org/wiki/The_Wheel_of_Time
    • Accelerando (Charles Stross): https://en.wikipedia.org/wiki/Accelerando
    • Charles Stross: https://en.wikipedia.org/wiki/Charles_Stross

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

15. Brittany Ellich: Using AI to Maintain Software, Not Rewrite It

    21 de enero de 20261 h 1 minEpisodio 217A continuación

    Rewrites are seductive. Clean slates promise clarity, speed, and “doing it right this time.” In practice, they’re often late, over budget, and quietly demoralizing.In this episode of Maintainable, Robby sits …

    Notas del episodio

    Rewrites are seductive. Clean slates promise clarity, speed, and “doing it right this time.” In practice, they’re often late, over budget, and quietly demoralizing.

    In this episode of Maintainable, Robby sits down with Brittany Ellich, a Senior Software Engineer at GitHub, to talk about a different path. One rooted in stewardship, readability, and resisting the urge to start over.

    Brittany’s career began with a long string of rebuild projects. Over time, she noticed a pattern. The estimates were wrong. Feature development stalled. Teams burned energy reaching parity with systems they’d already had. That experience pushed her toward a strong belief: if software is in production and serving users, it’s usually worth maintaining.

    [00:00:57] What well-maintained software actually looks like
    For Brittany, readability is the first signal. If code can’t be understood, it can’t be changed safely. Maintenance begins with making systems approachable for the next person.

    [00:01:42] Rethinking technical debt
    She explains how her understanding of technical debt has evolved. Rather than a fixed category of work, it’s often anything that doesn’t map directly to new features. Bugs, reliability issues, and long-term risks frequently get lumped together, making prioritization harder than it needs to be.

    [00:05:49] Why AI changes the maintenance equation
    Brittany describes how coding agents have made it easier to tackle small, previously ignored maintenance tasks. Instead of waiting for debt to accumulate into massive projects, teams can chip away incrementally. (Related: GitHub Copilot and the Copilot coding agent workflow she’s explored.)

    [00:07:16] Context from GitHub’s billing systems
    Working on metered billing at GitHub means correctness and reliability matter more than flash. Billing should be boring. When it’s not, customers notice quickly.

    [00:11:43] Navigating a multi-era codebase
    GitHub’s original Rails codebase is still in active use. Brittany relies heavily on Git blame and old pull requests to understand why decisions were made, treating them as a form of living documentation.

    [00:25:27] Treating coding agents like teammates
    Rather than delegating massive changes, Brittany assigns agents small, well-scoped tasks. She approaches them the same way she would a new engineer: clear instructions, limited scope, and careful review.

    [00:36:00] Structuring the day to avoid cognitive overload
    She breaks agent interaction into focused windows, checking in a few times a day instead of constantly monitoring progress. This keeps deep work intact while still moving maintenance forward.

    [00:40:24] Low-risk ways to experiment
    Improving test coverage and generating repository instructions are safe entry points. These changes add value without risking production behavior.

    [00:54:10] Navigating team resistance and ethics
    Brittany acknowledges skepticism around AI and encourages teams to start with existing backlog problems rather than selling AI as a feature factory.

    [00:57:57] Books, habits, and staying balanced
    Outside of software, Brittany recommends Atomic Habits by James Clear, sharing how small routines help her stay focused.

    The takeaway is clear. AI doesn’t replace engineering judgment. Used thoughtfully, it can support the unglamorous work that keeps software alive.

    Good software doesn’t need a rewrite.
    It needs caretakers.

    References Mentioned

    • GitHub – Brittany’s current role and the primary environment discussed
    • GitHub Universe – Where Brittany presented her coding agent workflow
    • Atomic Habits by James Clear – Brittany’s recommended book outside of tech
    • Overcommitted - Podcast Brittany co-hosts
    • The Balanced Engineer Newsletter – Brittany’s monthly newsletter on engineering, leadership, and balance
    • Brittany Ellich’s website – Central hub for her writing and links
    • GitHub Copilot – The AI tooling discussed throughout the episode
    • How the GitHub billing team uses the coding agent in GitHub Copilot to continuously burn down technical debt – GitHub blog post referenced

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

16. Kent L Beck: You’re Ignoring Optionality… and Paying for It

    9 de diciembre de 202550 minEpisodio 216A continuación

    Kent Beck: You’re Ignoring Optionality… and Paying for ItIn this episode of Maintainable, Robby speaks with Kent Beck, a foundational voice in modern software development and author of Tidy First?. Kent joins …

    Notas del episodio

    Kent Beck: You’re Ignoring Optionality… and Paying for It

    In this episode of Maintainable, Robby speaks with Kent Beck, a foundational voice in modern software development and author of Tidy First?. Kent joins from California to explore why optionality is a central, often underestimated dimension of maintainable software.

    Kent begins by describing the tension between features and future flexibility. Shipping new capabilities is easy to measure. Creating options for what comes next is not. That imbalance is where maintainability either flourishes or collapses. Senior developers in particular must learn to navigate this tension because they have lived through the consequences when no one does.

    They reflect on how cost models have shifted across the last five decades. Early in Kent’s career, computers were expensive and programmers were cheap. Today the balance often flips depending on scale. At massive scale, electricity and compute time become meaningful costs again. That variability shapes whether teams optimize for hardware efficiency or developer efficiency.

    Episode Highlights

    [00:00:46] The Two Forms of Software Value

    Kent explains why software value comes from both current features and the options you preserve for future work. He describes optionality as the invisible half of maintainability.

    [00:03:35] When Computers Become “Expensive” Again

    Robby and Kent revisit the shift from hardware-optimized development to developer-optimized development and how large-scale systems have reintroduced compute cost pressures.

    [00:07:25] Why the Question Mark in Tidy First?

    Kent shares why tidying is always a judgment call and why he put a question mark in the title.

    [00:10:14] The Real Cost of Speculative Flexibility

    They discuss why adding configurability too early creates waste and why waiting until just before you need it increases value.

    [00:13:46] Making Hard Changes Easy

    Kent outlines his guiding idea. When you face a difficult change, make the change easy first, then make the easy change.

    [00:17:08] The Feature Saw

    Kent explains his features versus options graph and how teams repeatedly burn optionality until they hit zero. At that point, forward movement becomes painful.

    [00:19:37] Why 100 Percent Utilization Is a Trap

    Kent discusses how queuing theory shows that full utilization pushes wait times toward infinity. Overcommitted teams have no room for design work.

    [00:22:44] Split Teams Do Not Solve the Problem

    Robby talks about consulting scenarios where “tidy teams” and “feature teams” are separated. Kent argues that this splits incentives and prevents optionality from being sustained.

    [00:26:15] Structure and Behavior Should Not Ship Together

    Kent describes why feature changes are irreversible, structure changes are reversible, and why combining them increases risk for everyone.

    [00:30:37] Tidying Reveals Intent

    While cleaning up structure, developers often uncover logic flaws or misunderstandings that were previously hidden.

    [00:32:00] When Teams Discourage Testing

    Kent shares stories about environments where developers were punished for refactoring or writing tests. He explains why building career options is essential in those situations.

    [00:37:57] Why Tidying Is an Ethical Obligation

    Kent reframes optionality as a moral responsibility. No one should make work harder for the next person who touches the code.

    [00:41:33] Succession and Slicing

    Kent describes how nearly every structural change can be broken into small, safe steps, even when the change first appears atomic.

    [00:47:00] A Small Habit to Start Today

    Kent suggests adding a blank line to separate conceptual chunks in long functions. It is a small step that improves clarity immediately.

    Resources Mentioned

    • Tidy First? by Kent Beck
    • Kent Beck on Substack
    • The Timeless Way of Building by Christopher Alexander

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

17. Don MacKinnon: Why Simplicity Beats Cleverness in Software Design

    2 de diciembre de 202551 minEpisodio 215A continuación

    Episode Highlights[00:00:48] What Makes Software MaintainableDon explains why unnecessary complexity is the biggest barrier to maintainability, drawing on themes from A Philosophy of Software Design.[00:03:14] …

    Notas del episodio

    Episode Highlights

    [00:00:48] What Makes Software Maintainable
    Don explains why unnecessary complexity is the biggest barrier to maintainability, drawing on themes from A Philosophy of Software Design.

    [00:03:14] The Cost of Clever Abstractions
    A real story from a Node.js API shows how an unused abstraction layer around MongoDB made everything harder without delivering value.

    [00:04:00] Shaping Teams and Developer Tools
    Don describes the structure of the Searchcraft engineering team and how the product grew out of recurring pain points in client projects.

    [00:06:36] Reducing Complexity Through SDK and Infra Design
    Why Searchcraft intentionally limits configuration to keep setup fast and predictable.

    [00:08:33] Lessons From Consulting
    Robby and Don compare consulting and product work, including how each environment shapes developers differently.

    [00:15:34] Inherited Software and Abandoned Dependencies
    Don shares the problems that crop up when community packages fall behind, especially in ecosystems like React Native.

    [00:18:00] Evaluating Third-Party Libraries
    Signals Don looks for before adopting a dependency: adoption, update cadence, issue activity, and whether the library is “done.”

    [00:19:40] Designing Code That Remains Understandable
    Why clear project structure and idiomatic naming matter more than cleverness.

    [00:20:29] RFCs as a Cultural Anchor
    How Don’s team uses RFCs to align on significant changes and avoid decision churn.

    [00:23:00] Documentation That Adds Context
    Documentation should explain why, not echo code. Don walks through how his team approaches this.

    [00:24:11] Type Systems and Maintainability
    How Don’s journey from PHP and JavaScript to TypeScript and Rust changed his approach to structure and communication.

    [00:27:05] Testing With Types
    Stable type contracts make tests cleaner and less ambiguous.

    [00:27:45] Building Trust in AI Systems
    Don discusses repeatability, hallucinations, and why tools like MCP matter for grounding LLM behavior.

    [00:29:28] AI in Developer Tools
    Search Craft’s MCP server lets developers talk to the platform conversationally instead of hunting through docs.

    [00:33:21] Improving Legacy Systems Slowly
    The Strangler pattern is a practical way to replace old systems one endpoint at a time.

    [00:34:11] Deep Work and Reducing Reactive Noise
    Don encourages developers to carve out time for uninterrupted thinking rather than bouncing between notifications.

    [00:36:09] Measuring Progress
    Build times, test speeds, and coverage provide signals teams can use to track actual improvement.

    [00:38:24] Changing Opinions Over a Career
    Why Don eventually embraced TypeScript after initially writing it off.

    [00:39:15] Industry Trends and Repeating Cycles
    SPAs, server rendering, and the familiar pendulum swing in web architecture.

    [00:41:26] Experimentation and Team Autonomy
    How POCs and side projects surface organically within Don’s team.

    [00:44:42] Growing Skills Through Intentional Goals
    Setting learning targets in 1:1s to support long-term developer growth.

    [00:47:19] Where to Find Don
    LinkedIn, Blue Sky, and his site: donmackinnon.dev.

    Resources Mentioned

    • A Philosophy of Software Design by John Ousterhout
    • John Ousterhout’s Maintainable.fm Interview (Episode 131)
    • Searchcraft
    • Elastic
    • Algolia
    • WordPress Plugin Directory
    • Request for Comments (RFC)
    • Strangler Fig Pattern
    • C2 Wiki
    • Model Context Protocol (MCP)
    • Glam AI
    • Aubrey/Maturin Series by Patrick O’Brian
    • Master and Commander
    • donmackinnon.dev

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

18. Chris Zetter: Building a Database to Better Understand Maintainability

    18 de noviembre de 202550 minEpisodio 214A continuación

    Episode SummaryIn this conversation, Robby sits down with software engineer and author Chris Zetter to explore what building a relational database from scratch can teach us about maintainability, architectural …

    Notas del episodio

    Episode Summary

    In this conversation, Robby sits down with software engineer and author Chris Zetter to explore what building a relational database from scratch can teach us about maintainability, architectural thinking, and team culture. Chris shares why documentation often matters more than perfectly shaped code, why pairing accelerates learning and quality, and why “boring technology” is sometimes the most responsible choice. Together they examine how teams get stuck in local maxima, how junior engineers build confidence, and how coding agents perform when asked to implement a database.

    Episode Highlights

    [00:01:00] What Makes Software Maintainable
    Chris explains that well-maintained software is defined by how effectively it helps teams deliver value and respond to change. In some domains—like payroll systems—the maintainability burden shifts toward documentation rather than code organization.

    [00:03:50] Documentation vs. Code Comments
    He describes visual docs, system diagrams, and commit–ticket links as more durable sources of truth than inline comments, which tend to rot and discourage refactoring.

    [00:05:15] Rethinking Technical Debt
    Chris argues that teams overuse the metaphor. He prefers naming the specific reason something is slow or brittle—like outdated libraries or rushed decisions—because that builds trust and clarity with product partners.

    [00:07:45] Where Core Debt Really Lives
    Earlier in his career he obsessed over long files; now he focuses on structural issues. Architecture, boundaries, and naming affect changeability far more than messy internals.

    [00:08:15] Pairing as the Default Tool
    Chris loves pairing for its speed, clarity, and shared context. Remote pairing has removed obstacles like mismatched keyboard setups or cramped office seating. Tools like Tuple and Pop keep it smooth.

    [00:10:20] The Mob Tool and Fast Driver Switching
    He explains how the Mob CLI tool makes switching drivers nearly instant, which keeps energy high and lets everyone work in their own editor environment, reducing friction and fatigue.

    [00:13:45] Pairing with Junior Engineers
    Pairing helps newer developers avoid painful pull-request rework and builds confidence. But teams must balance pairing with opportunities for engineers to build autonomy.

    [00:20:50] Getting Feedback Sooner
    Chris emphasizes speed of feedback: showing progress early to stakeholders prevents wasted days—and sometimes weeks—of heading in the wrong direction.

    [00:21:10] Boring Technology as a Feature
    After being burned by abandoned frameworks, Chris champions predictable, well-supported tools for the big layers: language, framework, database. Novelty is great—but only in places where rollback is cheap.

    [00:23:20] Balancing Professional Development with Organizational Needs
    Developers want experience with new technology; organizations want stability. Chris describes how leaders can channel curiosity safely and productively.

    [00:27:20] Build a Database Server
    Chris’s book, Build a Database Server, is a practical, language-agnostic guide to building a relational database from scratch. It uses a test suite as a feedback loop so developers can experiment, refactor, and learn architectural trade-offs along the way.

    [00:31:45] What Writing the Book Taught Him
    Creating a database deepened his appreciation for Postgres maintainers. He highlights the number of moving parts—storage engine, type system, query planner, wire protocol—and how academic papers often skip hands-on guidance.

    [00:33:00] Experimenting with Coding Agents
    Chris tested coding agents by giving them the book’s test suite. They passed many tests but produced brittle, incoherent architecture. Without a feedback loop for quality, the agents aimed only to satisfy test conditions—not build maintainable systems.

    [00:36:55] Escaping a Local Maxima Through a Design Sprint
    Chris shares a story of a team stuck maintaining a system that no longer fit business needs. A design sprint gave them space to reimagine the system, clarify naming, validate concepts, and identify which pieces were worth reusing.

    [00:40:40] Rewrite vs. Refactor
    He leans toward refactor for large systems but supports small, isolated rewrites when boundaries are clear.

    [00:41:40] Building Trust in Legacy Code
    When inheriting an old codebase, Chris advises starting with a small bug fix or UI tweak to understand deployment pipelines, test coverage, and failure modes before tackling bigger improvements.

    [00:43:20] Recommended Reading
    Chris recommends _Turn the Ship Around! for its lessons on empowering teams to act with intent instead of waiting for permission.

    Resources Mentioned

    • Build a Database Server
    • Chris Zetter’s blog
    • The Mob Programming CLI Tool
    • Tuple
    • Pop
    • Turn the Ship Around!

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

19. Denis Rechkunov: When Consistency Becomes a Culture

    28 de octubre de 20251 h 7 minEpisodio 213A continuación

    Maintaining consistency across a sprawling codebase is one of the hardest challenges in software engineering. Denis Rechkunov, a Principal Software Engineer at Elastic, joins Robby to share how his team turned …

    Notas del episodio

    Maintaining consistency across a sprawling codebase is one of the hardest challenges in software engineering. Denis Rechkunov, a Principal Software Engineer at Elastic, joins Robby to share how his team turned consistency into a cultural practice rather than a technical checklist. From managing open source projects with hundreds of contributors to experimenting safely with new patterns, Denis believes maintainability begins with shared ownership, not just clean code.

    He explains how Elastic introduced automation and linters to improve cohesion without discouraging creativity. Instead of enforcing perfection across the entire system, Denis’ team scopes their changes to manageable areas and rewards steady progress over sweeping rewrites. Their annual “On Week” tradition gives engineers space to fix what frustrates them most, showing how small, focused bursts of work can produce big leaps in stability and morale.

    The conversation also explores the human side of maintainability. Denis recalls early lessons about unclear expectations, the importance of documenting decisions in public pull requests, and how open feedback loops build trust across remote teams. Whether it’s stabilizing a flaky CI pipeline or mentoring new engineers, Denis argues that technical excellence thrives when consistency becomes a habit shared by everyone.

    Episode Highlights

    [00:01:02] Defining Well-Maintained Software
    Denis identifies consistency, documentation, testability, and agility as the key ingredients of maintainable systems.

    [00:02:22] Balancing Standards and Autonomy
    How automation and linters help preserve code cohesion while minimizing interpersonal friction.

    [00:04:08] Experimenting Safely
    Elastic scopes new patterns to low-risk modules before broader adoption, avoiding mass rewrites.

    [00:07:19] Incremental Cleanup
    Linters only apply to changed files, helping the team fix issues gradually without overwhelming contributors.

    [00:08:02] Maintainability as a People Problem
    Denis highlights that sustainable systems depend more on culture and mentorship than on architecture.

    [00:10:13] Lessons from Miscommunication
    An early experience showed the cost of undocumented conventions and unclear onboarding.

    [00:17:09] Making Space for Technical Debt
    Elastic’s engineers dedicate part of each sprint and an annual “On Week” to tackle maintenance work.

    [00:23:05] Restoring CI Reliability
    Denis shares how the team revived a pipeline with only a 10% success rate by categorizing failures and focusing on data.

    [00:32:00] Practicing Software Archaeology
    He stresses the value of documenting discussions in pull requests to avoid historical guesswork later.

    [00:36:09] Feedback and Trust
    Open communication, humility, and mutual feedback loops form the backbone of a maintainable culture.

    [00:51:00] Embracing Chaos in Open Source
    Denis encourages teams to accept a degree of entropy and focus their efforts on user-facing stability.

    [01:00:00] Security and Privacy
    Why maintainability, trust, and privacy are inseparable pillars of long-term sustainability.

    [01:01:06] Where to Start
    Instead of rewriting code, start by cultivating maintainability as a shared value across the team.

    Resources Mentioned

    • Elastic
    • golangci-lint
    • AppSignal
    • The Caves of Steel by Isaac Asimov — Denis’ recommendation inspired Robby to finally pick up a copy and start reading it himself.
    • Denis’s Blog – rdner.de
    • Denis on GitHub
    • Denis on Mastodon
    • Denis on LinkedIn

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

20. Nathan Ladd: Relentless Improvement and the Cost of Neglect

    14 de octubre de 202555 minEpisodio 212A continuación

    Episode NotesThe discussion moves into how standards evolve beyond tools, the trade-offs of monocultures vs. consensus-driven teams, and why ownership matters when the original authors move on. Nathan also …

    Notas del episodio

    Episode Notes

    The discussion moves into how standards evolve beyond tools, the trade-offs of monocultures vs. consensus-driven teams, and why ownership matters when the original authors move on. Nathan also unpacks the cost of neglect, describing defects as anything that slows developers down—not just issues that impact end users.

    Later in the conversation, Nathan recounts a migration from a React SPA to Turbo and Stimulus that removed barriers between designers and developers. He highlights how keeping all problems on the radar together prevents teams from falling into local optima. The episode closes with reflections on TestBench, blind spots in testing, continuous improvement in remote teams, and advice for developers who feel stuck raising maintenance concerns.

    Episode Highlights

    [00:01:07] Defining Well-Maintained Software: Nathan shares his three key markers—up-to-date dependencies, adherence to team standards, and fixing defects immediately.

    [00:02:53] From Tools to Tacit Knowledge: Why norms start with tool-enforced rules like RuboCop but evolve into cultural agreements within teams.

    [00:04:49] Speed vs. Durability: Teams built on monoculture move quickly early on, but diverse, consensus-driven cultures go farther.

    [00:11:11] Owning the Architecture: When original developers leave, new teams must take responsibility for architecture rather than defer decisions.

    [00:13:37] The Cost of Neglect: Dependencies, drifting standards, and defects interact in compounding ways. Nathan reframes defects as “anything that impedes developer effectiveness.”

    [00:17:46] React → Turbo + Stimulus Migration: A costly SPA and siloed design team gave way to a simpler approach that reduced rework and empowered designers to contribute directly.

    [00:22:44] Avoiding Local Optima: Tackling problems in isolation creates dead ends—addressing them holistically opens real paths forward.

    [00:24:32] Who We Seek Validation From: Developer identities often align with whose approval they value—shaping front-end vs. back-end divides.

    [00:27:34] Comfort vs. Maintenance Burden: Silos built for comfort create tomorrow’s maintenance problems.

    [00:33:45] Relentless Improvement in Remote Teams: Start as an ensemble, evolve into autonomous work cells, and use work logs to sustain consensus.

    [00:38:33] What’s Missing from Remote Work: Nathan reflects on lost “hallway conversations” and the challenge of building social glue remotely.

    [00:40:50] The Story Behind TestBench: Dissatisfaction with existing frameworks and a desire for simplicity led to TestBench’s creation.

    [00:47:38] Testing Blind Spots: The biggest blind spot is equating testing with automation—interactive testing and intelligible output remain essential.

    [00:50:35] Advice for Stuck Engineers: Nathan encourages developers to study quality traditions, connect with peers, and embrace continuous improvement.

    [00:53:16] Book Recommendations: Deming’s Out of the Crisis and The New Economics, Toyota’s product development work, and Rawls’ A Theory of Justice.

    Tools & Resources Mentioned

    • Brightworks Digital – Nathan’s current company, where he serves as Principal.
    • Nathan Ladd on LinkedIn – Connect with Nathan and follow his work.
    • TestBench – A Ruby testing framework co-created by Nathan.
    • Turbo – Hotwire framework for building modern, fast applications without heavy JavaScript.
    • Stimulus – A modest JavaScript framework for enhancing HTML with small, reusable controllers.
    • RSpec – A popular Ruby testing tool for behavior-driven development.
    • Minitest – A simple and fast Ruby testing framework.
    • RuboCop – A Ruby static code analyzer and formatter.
    • Lessons Learned in Software Testing – Classic book on testing by Cem Kaner, James Bach, and Bret Pettichord.
    • Out of the Crisis – W. Edwards Deming’s influential work on quality and systems thinking.
    • The New Economics – Deming’s follow-up book on continuous improvement.
    • A Theory of Justice – John Rawls’ seminal work on moral and political philosophy.
    • The Toyota Product Development System – Insights into Toyota’s continuous improvement and development practices.

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

21. Taylor Otwell: What 14 Years of Laravel Taught Me About Maintainability

    26 de agosto de 202556 minEpisodio 211A continuación

    Taylor Otwell, creator of Laravel and CEO of Laravel LLC, joins Robby to reflect on his 14-year journey building and maintaining one of the most popular web frameworks in the world. From its PHP 5.3 origins to …

    Notas del episodio

    Taylor Otwell, creator of Laravel and CEO of Laravel LLC, joins Robby to reflect on his 14-year journey building and maintaining one of the most popular web frameworks in the world. From its PHP 5.3 origins to a full-time business with a 70-person team, Taylor shares what he's learned about code maintainability, developer experience, and what it means to evolve without overcomplicating things.

    He discusses the importance of simplicity in software design, why sticking to framework conventions leads to better long-term outcomes, and how his minimalist mindset continues to shape Laravel today. Taylor also opens up about the moment he felt out of ideas, how Laravel’s 2024 funding round marked a new chapter, and what it’s like to hand off more responsibility while staying involved in the open source core.

    Episode Highlights

    [00:01:07] Taylor’s Definition of Maintainable Software  
    Simplicity, understandability, and confidence in making changes are key themes in Taylor's approach to longevity in software.

    [00:02:13] Kenny vs. the Terminator: A Metaphor for Code  
    Why Taylor believes software should be disposable and adaptable, not rigid and overbuilt.

    [00:05:39] Laravel’s Unexpected Traction  
    Taylor shares the early days of Laravel and the moment he realized the project had legs.

    [00:10:30] Who Laravel Is Built For  
    Taylor talks about designing for the “average developer” and balancing his own preferences with those of a broader community.

    [00:14:50] Curating a Growing Project—Solo  
    Despite Laravel’s scale, Taylor remains the sole curator of the open source core and explains why that hasn’t changed (yet).

    [00:18:00] From Scripts to Business  
    How Laravel’s first commercial product came out of a personal need—and pushed Taylor to go full time.

    [00:20:00] Making Breaking Changes  
    Taylor explains Laravel’s evolution and why he now tries to avoid breaking backward compatibility.

    [00:25:00] Stick to the Conventions  
    The Laravel apps that age best are the ones that don’t get too clever, Taylor says—because the clever dev always moves on.

    [00:27:00] Recognizing “Cleverness” as a Smell  
    Advice for developers who may unknowingly be over-engineering their way into future technical debt.

    [00:30:00] Making Decisions by Comparing Real Code  
    Taylor explains why he always brings discussions back to reality by looking at code side-by-side.

    [00:34:00] Dependency Injection vs. Facades  
    Why most Laravel developers stick with facades, and how architectural trends have changed.

    [00:41:00] Laravel’s Evolution Around Static Analysis  
    Taylor talks about embracing PHP's maturing type system while staying true to the dynamic roots of the framework.

    [00:43:00] A Shift in Laravel’s Testing Culture  
    How Adam Wathan’s course reshaped the community’s approach to feature testing in Laravel apps.

    [00:48:09] What Keeps Laravel Interesting Now  
    Taylor reflects on transitioning from solving his own problems to empowering a larger team—and why that’s the new challenge.

    Resources & Links

    • Laravel
    • Laravel Changelog
    • Taylor on X (Twitter)
    • Taylor on Bluesky
    • Elements of Style – William Strunk Jr.
    • Adam Wathan's “Test-Driven Laravel” course

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time! 

    Use the code maintainable to get a 10% discount for your first year. Check them out!

     

    NOTE: Planet Argon, the organization that produces this podcast, works inside of Laravel applications that need development work, a migration, or maintenance.

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

22. Sara Jackson: Why Resilience Is a Team Sport

    22 de julio de 202553 minEpisodio 210A continuación

    Robby is joined by Sara Jackson, Senior Developer at thoughtbot, to explore the practical ways teams can foster resilience—not just in their infrastructure, but in their everyday habits. They talk about why …

    Notas del episodio

    Robby is joined by Sara Jackson, Senior Developer at thoughtbot, to explore the practical ways teams can foster resilience—not just in their infrastructure, but in their everyday habits. They talk about why documentation is more than a chore, how to build trust in test suites, and how Chaos Engineering at the application layer can help make the case for long-term investment in maintainability.

    Sara shares why she advocates for writing documentation on day one, how “WET” test practices have helped her avoid brittle test suites, and why she sees ports as a powerful alternative to full rewrites. They also dive into why so many teams overlook failure scenarios that matter deeply to end users—and how being proactive about those situations can shape better products and stronger teams.

    Episode Highlights

    [00:01:28] What Well-Maintained Software Looks Like: Sara champions documentation that’s trusted, updated, and valued by the team.

    [00:07:23] Invisible Work and Team Culture: Robby and Sara discuss how small documentation improvements often go unrecognized—and why leadership buy-in matters.

    [00:10:34] Why Documentation Should Start on Day One: Sara offers a “hot take” about writing things down early to reduce cognitive load.

    [00:16:00] What Chaos Engineering Really Is: Sara explains the scientific roots of the practice and its DevOps origins.

    [00:20:00] Application-Layer Chaos Engineering: How fault injection can reveal blind spots in the user experience.

    [00:24:36] Observability First: Why you need the right visibility before meaningful chaos experiments can begin.

    [00:28:32] Pitching Resilience to Stakeholders: Robby and Sara explore how chaos experiments can justify broader investments in system quality.

    [00:33:24] WET Tests vs. DRY Tests: Sara explains why test clarity and context matter more than clever abstractions.

    [00:40:43] Working on Client Refactors: How Sara approaches improving test coverage before diving into major changes.

    [00:42:11] Rewrite vs. Refactor vs. Port: Sara introduces “porting” as a more intentional middle path for teams looking to evolve their systems.

    [00:50:45] Delete More Code: Why letting go of unused features can create forward momentum.

    [00:51:13] Recommended Reading: Being Wrong by Kathryn Schulz.

    Resources & Links

    • Sara on Mastodon
    • thoughtbot
    • RubyConf 2024 Talk – Chaos Engineering on the Death Star
    • Book: Being Wrong by Kathryn Schulz
    • Flu Shot on GitHub
    • ChaosRB on GitHub
    • Semian from Shopify — a chaos engineering toolkit for Ruby

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

23. Joel Chippindale: Why High-Quality Software Isn’t About Developer Skill Alone

    1 de julio de 202557 minEpisodio 209A continuación

    CTO coach Joel Chippindale joins Robby to share what he's learned over two decades of building and leading software teams. Joel argues that maintainability has less to do with “clean code” and more to do with …

    Notas del episodio

    CTO coach Joel Chippindale joins Robby to share what he's learned over two decades of building and leading software teams. Joel argues that maintainability has less to do with “clean code” and more to do with how teams communicate, prioritize, and make progress visible. Drawing on his time at Unmade and his current coaching practice, Joel outlines practical ways teams can build trust, navigate brittle systems, and stop letting technical debt conversations get lost in translation.

    Episode Highlights

    [00:01:10] A Working Definition of Maintainability
    Joel explains why “software that’s easy to keep changing” is the gold standard—and why context matters as much as code.

    [00:05:24] The Pitfalls of Pre-Optimization
    How developers can trap themselves by designing for futures that may never arrive.

    [00:10:40] Challenging the Iron Triangle
    Joel pushes back on the idea that teams must sacrifice quality for speed or cost.

    [00:15:31] Quality Is a Team Conversation
    Why code quality starts long before you open your editor.

    [00:20:00] Unmade Case Study: From Chaos to Confidence
    How Joel helped a struggling team at Unmade regain trust by delivering less—and showing more.

    [00:28:08] Helping Business Stakeholders Buy Into Maintenance Work
    How to reframe backend investments in terms that resonate across departments.

    [00:33:40] First Steps for Fragile Systems
    What Joel looks for when coaching teams overwhelmed by legacy code.

    [00:41:32] The Value of Boring Technology
    Why solving real problems matters more than chasing resume polish.

    [00:45:20] The Case for Coaching
    What makes leadership coaching valuable—and why it's not a sign of weakness.

    [00:51:10] Building Your Manager Voltron
    Joel shares why every developer should cultivate their own support system, including mentors, peers, and coaches.

    Resources & Mentions

    • Joel’s Coaching Site – Monkey’s Thumb
    • Joel on Mastodon
    • “Take Back Control of Code Quality” – Joel’s Blog Post
    • “Manager Voltron” by Lara Hogan
    • Never Split the Difference by Chris Voss

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

24. Melanie Sumner: Why Continuous Accessibility Is a Strategic Advantage

    10 de junio de 202550 minEpisodio 208A continuación

    Melanie Sumner: Why Continuous Accessibility Is a Strategic AdvantageMelanie Sumner, Product Accessibility Lead for Design Systems at HashiCorp, joins Robby to talk about what it takes to scale accessibility …

    Notas del episodio

    Melanie Sumner: Why Continuous Accessibility Is a Strategic Advantage

    Melanie Sumner, Product Accessibility Lead for Design Systems at HashiCorp, joins Robby to talk about what it takes to scale accessibility across legacy products—and how aligning design and engineering processes creates lasting change. Melanie shares her work making Ember.js more accessible, her team’s philosophy behind their design system, and why she treats accessibility like any other technical concern.

    From the pitfalls of nested interactive elements to the strengths of Ember's conventions and codemods, this conversation offers a roadmap for integrating accessibility into every layer of product development.

    Melanie also reflects on why she trademarked the term Continuous Accessibility, how it fits into product lifecycles, and what other frameworks can learn from the Ember community’s approach.

    “Accessibility is a technical problem with a technical solution.”

    Melanie joins us from Chicago, Illinois.

    Episode Highlights

    [00:01:00] What Well-Maintained Software Looks Like: Consistency, purpose, and bridging design and engineering
    [00:02:30] Building a Unified Design System Across 10+ Legacy Products
    [00:03:30] Creating Component Requirements Before Design or Code
    [00:05:00] Designing with Accessibility Defaults—and Providing Bridges for Legacy
    [00:07:00] How Ember’s Conventions Help Scale Front-End Systems
    [00:09:30] Who Uses Ember—and Why It's a Fit for Teams with Big Requirements
    [00:13:30] Technical Debt in Design Systems and the Cost of Rushing
    [00:16:30] How They Future-Proof Components and Avoid Over-Engineering
    [00:19:00] What “Continuous Accessibility” Means in Practice
    [00:21:00] Accessibility Testing and the Limits of Automation
    [00:23:00] Common Accessibility Mistakes: Nested Interactives and Misused DIVs
    [00:24:30] Keyboard Navigation as a Litmus Test
    [00:26:00] Text Adventure Games and Accessibility as a Playable Experience
    [00:28:30] The Origin of Her Accessibility Journey at UNC Chapel Hill
    [00:31:00] Why She Avoids Framing Accessibility in Emotional Terms
    [00:32:45] Compliance as a Business Driver for Accessibility
    [00:35:00] Open Source Work on Testing Rules Across Frameworks
    [00:38:00] The Navigation API and Fixing Single-Page App Accessibility
    [00:40:30] HTML’s Forgiveness and the Illusion of “Good Enough”
    [00:43:00] Advice for Engineers Advocating for Accessibility Without Authority
    [00:46:45] Book Recommendation: Cradle Series by Will Wight
    [00:48:30] Where to Follow Melanie: melanie.codes

    Links and Resources

    • Melanie's Website
    • Helios Design System at HashiCorp
    • Cradle Series by Will Wight
    • Ember Community Survey
    • A11y Automation GitHub Project
    • Axe-core

    Follow Melanie:

    • GitHub
    • LinkedIn

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

25. Joe Masilotti: Simplify Your Stack, Ship Mobile Sooner

    20 de mayo de 202556 minEpisodio 207A continuación

    In this episode of Maintainable, Robby speaks with Joe Masilotti, an independent consultant who helps Rails teams ship mobile apps using Hotwire Native.Joe shares his perspective on what makes software …

    Notas del episodio

    In this episode of Maintainable, Robby speaks with Joe Masilotti, an independent consultant who helps Rails teams ship mobile apps using Hotwire Native.

    Joe shares his perspective on what makes software maintainable—especially for consultants who need to onboard quickly. He explains why setup scripts often add unnecessary complexity, and how he evaluates a project’s maintainability by how quickly he can go from clone to coding.

    Robby and Joe also discuss how hybrid mobile development can offer faster delivery, fewer bugs, and better long-term flexibility—especially when teams reuse their existing Rails web views. Joe explains how Hotwire Native allows teams to incrementally introduce native features without rewriting their entire app.

    Whether you’re maintaining a mobile shell built two years ago or just starting to explore native development, Joe offers actionable advice on setting expectations, scoping client work, and navigating modern mobile tech stacks.

    ⏱️ Episode Highlights

    [00:01:17] Onboarding as a Measure of Maintainability
    Joe shares how quickly he can spin up a Rails app often reflects how maintainable it is.

    [00:05:12] Being a Good Guest in Someone Else’s Codebase
    Joe outlines his ideal onboarding checklist and how he adapts to unfamiliar environments.

    [00:08:00] Setting Communication and Collaboration Expectations
    The three questions Joe asks every client to understand how their team works.

    [00:13:02] Offering Opinions—Only Where Invited
    Why Joe stays scoped to the work he’s hired for, even when tempted to fix more.

    [00:14:15] When Technical Debt Enters the Conversation
    Joe explains how debt discussions usually emerge after version one is shipped.

    [00:15:33] Who Should Read Hotwire Native for Rails Developers
    Joe describes the type of developer his book is written for and what it covers.

    [00:18:01] Choosing Native vs. Hybrid for Your Rails App
    A framework comparison based on your current frontend architecture.

    [00:20:00] Introducing the Hotwire Native Mindset
    Why logic belongs on the server and the client should stay thin.

    [00:21:00] Bridge Components: How Rails, iOS, and Android Connect
    Joe walks through how native and web technologies pass data between layers.

    [00:24:00] Why Even a Web View-Based App is Worth Shipping
    The practical benefits of discoverability, push notifications, and native APIs.

    [00:28:01] Replacing Unmaintainable Apps with Hotwire Native
    Joe describes how hybrid rewrites often reduce mobile code by 90%.

    [00:31:33] Letting Go of Feature Parity
    Why most clients end up cutting features they originally wanted to preserve.

    [00:32:18] Scoping and Estimating Project-Based Work
    How Joe uses repeatable patterns to price fixed-fee consulting engagements.

    [00:35:15] Using AI to Translate Between Tech Stacks
    Joe shares how he leverages LLMs to explore unfamiliar languages like Kotlin.

    [00:42:26] Long-Term Maintainability and When to Touch the Code
    Why some apps don’t need changes for years—and that’s okay.

    [00:43:43] Why Hybrid Apps Are Easier to Replace
    Joe explains why hybrid apps are often more disposable and less risky than monolithic web apps.

    🔗 Resources Mentioned:

    • Joe’s Book: Hotwire Native for Rails Developers
    • Joe’s Newsletter
    • Hotwire Native Mindset Article
    • Please Unsubscribe, Thanks by Julio Vincent Gambuto

    Follow Joe on X (formerly Twitter) and visit masilotti.com to learn more.

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

26. Freedom Dumlao: What 70 Java Services Taught Me About Focus

    22 de abril de 20251 h 3 minEpisodio 206A continuación

    Freedom Dumlao (CTO at Vestmark) joins Robby to explore what it means to maintain software at scale—and why teams sometimes need to unlearn the hype.With two decades of experience supporting financial systems …

    Notas del episodio

    Freedom Dumlao (CTO at Vestmark) joins Robby to explore what it means to maintain software at scale—and why teams sometimes need to unlearn the hype.

    With two decades of experience supporting financial systems, Freedom shares how his team manages a Java monolith that oversees $1.6 trillion in assets. But what’s most surprising? His story of how a team working on 70+ microservices rebuilt their platform as a single Ruby on Rails monolith—and started shipping faster than ever before.

    Episode Highlights

    [00:02:00] Why Respecting Legacy Code Matters
    Freedom reflects on a lesson he learned at Amazon: "Respect what came before." He discusses the value of honoring the decisions of past developers—especially when their context is unknown.

    [00:05:00] How Tests Help (and Where They Don’t)
    Freedom discusses how tests can clarify system behavior but not always intent—especially when market logic or business-specific rules come into play.

    [00:07:00] The Value of Understudies in Engineering
    Freedom shares how his team intentionally pairs subject matter experts with understudies to reduce risk and transfer knowledge.

    [00:09:30] Rethinking Technical Debt
    He challenges the fear-based framing of technical debt, comparing it instead to a strategic mortgage.

    [00:17:00] From 70 Services to 1 Monolith
    At FlexCar, Freedom led an unconventional rewrite—consolidating 70 Java microservices into a single Rails app. The result? A dramatic increase in velocity and ownership.

    [00:25:00] Choosing Rails Over Phoenix, Laravel, and Django
    After evaluating multiple frameworks, Rails' cohesiveness, Hotwire, and quick developer ramp-up made it the clear winner—even converting skeptical team members.

    [00:31:00] How Rails Changed Team Dynamics
    By reducing dependency handoffs, the new Rails app enabled solo engineers to own complete features. The impact? Faster delivery and more engaged developers.

    [00:36:30] Why Rails Still Makes Sense at a 20-Year-Old Company
    Even with a large Java codebase, Vestmark uses Rails for rapid prototyping and new product development.

    [00:41:00] Using AI to Navigate Legacy Systems
    Freedom explains how his team uses retrieval-augmented generation (RAG) to surface relevant code—but also the limitations of AI on older or less common codebases.

    [00:51:00] Seek Feedback, Not Consensus
    Freedom explains why aiming for alignment slows teams down—and how decision-makers can be inclusive without waiting for full agreement.

    Links and Resources

    • Freedom Dumlao on LinkedIn
    • Vestmark
    • No Rules Rules
    • Dungeon Crawler Carl series

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

27. Mercedes Bernard: Friendly Code Welcomes Everyone In

    8 de abril de 202549 minEpisodio 205A continuación

    Mercedes Bernard, Staff Software Engineer at Kit, joins Robby to talk about what it really means to write code that lasts—and who it should be written for.In this episode of Maintainable, Mercedes shares a …

    Notas del episodio

    Mercedes Bernard, Staff Software Engineer at Kit, joins Robby to talk about what it really means to write code that lasts—and who it should be written for.

    In this episode of Maintainable, Mercedes shares a thoughtful and practical perspective on working with legacy codebases, managing technical debt, and creating a team culture that values maintainability without fear or shame. Her guiding principle? Well-maintained software is friendly software—code that is understandable and approachable, especially for early-career developers.

    Together, they discuss how to audit and stabilize older systems, avoid full rewrites, and create consistent developer experiences in large applications. Mercedes reflects on her decade in consulting and how that shaped her approach to navigating incomplete documentation, missing historical context, and multiple competing patterns in a codebase. She breaks down different types of technical debt, explains why not all of it is inherently bad, and offers strategies for advocating for maintenance work across engineering and product teams.

    The conversation also touches on architecture patterns like job fan-out, measuring performance regressions, reducing infrastructure load, and building momentum for improvements even when leadership isn’t actively prioritizing them.

    If you’ve ever felt overwhelmed by a messy project or struggled to justify maintenance work, this episode will leave you with a fresh mindset—and a few practical tactics—for making code more sustainable and inclusive.

    Episode Highlights

    [00:01:08] Defining Well-Maintained Software
    Mercedes explains her top metric: software that feels friendly, especially to early-career developers navigating the codebase for the first time.

    [00:03:00] What Friendly Code Actually Looks Like
    She shares why consistency, discoverability, and light documentation (like class comments or UML snippets) can make a huge difference.

    [00:05:00] Assessing Code Like a House Tour
    Mercedes introduces her metaphor of giving a house tour to evaluate code: does everything feel like it’s in the right place—or is the stove in the cabinet?

    [00:06:53] Consulting Mindset: Being a Guest in the Codebase
    With a decade of consulting experience, Mercedes shares how she navigates legacy systems when historical context is long gone.

    [00:10:40] Stabilizing a Startup’s Tangled Architecture
    She walks through an in-depth case study where she helped a client with multiple abandoned services get back to stability—without a rewrite.

    [00:17:00] The Power of a One-Line Fix
    Mercedes shares how a missing check caused a job to fan out 30 million no-op background jobs a day—and how one line of code reduced that by 75%.

    [00:23:40] Why State Checks Belong Everywhere
    She explains how defense-in-depth patterns help avoid job queue flooding and protect system resources early in the fan-out process.

    [00:24:59] Reframing Technical Debt
    Not all debt is bad. Mercedes outlines three types—intentional, evolutionary, and time-based—and how to approach each one differently.

    [00:28:00] Why Teams Fall Behind Without Realizing It
    Mercedes and Robby talk about communication gaps between engineers and product stakeholders—and why it’s not always clear when tech debt starts piling up.

    [00:34:00] Quantifying Developer Friction
    Mercedes recommends expressing technical debt in terms of lost time, slow features, and increased cost rather than vague frustrations.

    [00:42:00] Getting Momentum Without Permission
    Her advice to individual contributors: start small. Break down your frustrations into bite-sized RFCs or tickets and show the impact.

    [00:45:40] Letting the Team Drive Standards
    Mercedes encourages team-led conventions over top-down declarations, and explains why having any decision is better than indecision.

    [00:47:54] Recommended Reading
    She shares a surprising favorite: The Secret Life of Groceries, a systems-thinking deep dive into the grocery industry by Benjamin Lorr.

    Resources & Links

    • 🧠 Mercedes Bernard’s website
    • 🛠 Kit
    • 📘 The Secret Life of Groceries by Benjamin Lorr
    • 🔎 Fan-out Pattern – Martin Fowler (for deeper context on fan-out job strategies)
    • 💬 Mercedes on LinkedIn

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

28. Evan Phoenix: The Why of the One Line

    1 de abril de 20251 h 9 minEpisodio 204A continuación

    Evan Phoenix (@evanphx), CEO of Miren, joins Robby to explore the subtle but powerful difference between writing code that works and writing code that explains itself. They discuss the role of clarity in …

    Notas del episodio

    Evan Phoenix (@evanphx), CEO of Miren, joins Robby to explore the subtle but powerful difference between writing code that works and writing code that explains itself. They discuss the role of clarity in maintainable systems, why splitting a monolith can backfire, and what developers can learn from artists and tradespeople alike.

    Episode Highlights

    [00:01:30] What Makes Software Maintainable?
    Evan defines maintainability as how easily a newcomer can make a change with minimal context.

    [00:02:30] Why Business Logic Should Be Obvious
    A discussion on domain knowledge leakage and abstracting rules like “can we sell today?”

    [00:05:00] Programming 'Mouthfeel' and the Trap of Prefactoring
    Evan explains why prematurely optimizing for reuse can lead to unnecessary complexity.

    [00:07:00] When to Extract Logic: The Copy/Paste Signal
    A practical approach to identifying reusable components by spotting repeated code.

    [00:08:00] Technical Debt as a Reflection of Cognitive Load
    Why forgetting your own code doesn’t automatically mean it’s “bad” code.

    [00:10:30] Testing as Emotional Insurance
    How writing even basic checks can build team confidence—especially when test coverage is weak.

    [00:13:00] Daily Integration Tests: A Low-Pressure Safety Net
    Using nightly integration runs to catch invisible bugs in complex systems.

    [00:14:00] Confidence > 100% Test Coverage
    Why fast feedback loops matter more than aiming for exhaustive tests.

    [00:20:00] Splitting the Monolith: A Cautionary Tale
    Evan shares how decoupling apps without decoupling the database created chaos.

    [00:22:00] Shared Models, Split Repos, and Hidden Pitfalls
    The unexpected bugs that emerge when two apps maintain duplicate models and validations.

    [00:23:00] Better Alternatives to Splitting Codebases
    How separate deployments and tooling can mimic team separation without architectural debt.

    [00:28:00] The Hidden Cost of Diverging Business Domains
    When apps evolve independently, business logic begins to drift—undermining consistency.

    [00:29:00] Building Miren and Staying Motivated
    How Evan approaches early-stage product development with curiosity and detachment.

    [00:36:00] How to Know When Your Open Source Project Is “Done”
    Reframing “dead” projects as complete—and why stability is often a feature.

    [01:01:00] Signals for Trusting Open Source Dependencies
    Evan’s mental checklist for evaluating if a library is worth adopting.

    [01:07:00] The Importance of Hiring Junior Developers
    Why investing in beginners is crucial for the future of our industry.

    [01:08:00] Book Recommendations
    Evan recommends The Inner Game of Tennis and Snow Crash.

    Links and Resources

    • Evan Phoenix’s Website
    • Evan on GitHub
    • Evan on Mastodon

    Book Recommendations

    • The Inner Game of Tennis (book)
    • Snow Crash by Neal Stephenson

    Thanks to Our Sponsor!

    Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.

    It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.

    Keep your coding cool and error-free, one line at a time!

    Use the code maintainable to get a 10% discount for your first year. Check them out!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

29. Chris Salvato: Building Developer Paradise by Sitting in the Problem Space

    25 de marzo de 202547 minEpisodio 203A continuación

    Software isn’t always about rapid iteration. Sometimes, the real challenge lies in carefully assessing the existing environment. Chris Salvato, a Senior Staff Engineer at Shopify, believes that spending time in …

    Notas del episodio

    Software isn’t always about rapid iteration. Sometimes, the real challenge lies in carefully assessing the existing environment. Chris Salvato, a Senior Staff Engineer at Shopify, believes that spending time in the “problem space” is vital for any long-lived application. Rather than diving immediately into controllers and tests, he begins by talking to everyone who interacts with the code—engineers, product owners, even directors who oversee strategy. This approach reveals hidden friction points that rarely come to light in larger, more formal meetings.

    When code grows organically over years, a range of issues emerges. Small workarounds might accumulate, new features can overlap with older ones, and domain boundaries become murky. Chris suggests mapping these overlaps through in-depth conversations so the team can pinpoint what genuinely obstructs productivity. He emphasizes that many developers may focus on surface fixes—updating a library here, renaming a class there—without acknowledging underlying confusion in the domain model itself. Removing extraneous code, clarifying domain entities, and aligning the team’s understanding can drastically reduce missteps.

    An interesting aspect of Chris’s method is his view of “developer paradise.” A codebase reaches this state when new contributors can navigate it with minimal help. Instead of sifting through endless documentation or complex wikis, they can figure out how classes, modules, and services connect simply by reading the code. Chris notes that achieving this often involves pruning unnecessary files or responsibilities. The end result is software that “self-documents,” easing onboarding and reducing reliance on external explanations.

    The conversation also touches on how large language models (LLMs) fit into the puzzle. Many organizations see AI-driven coding assistants as a way to accelerate development. Chris agrees they have potential, yet highlights a critical requirement: the code must be well-organized. If the system is sprawling and inconsistent, these tools may only add confusion. Lean, carefully segmented projects let both people and AI more effectively track what’s happening under the hood.

    Reducing code bloat leads naturally to discussions about prioritizing. Chris encourages teams not to tackle every annoyance at once. He references the importance of framing a unifying question, such as “Which feature or aspect of the app causes the greatest confusion among team members?” Spending too little time on this question, he warns, results in half-hearted improvements that eventually revert back to chaos. By contrast, devoting a few dedicated sprints—guided by thoughtful one-on-one interviews—can create lasting changes that set the entire codebase on a better trajectory.

    One intriguing theme is how personal growth ties into organizational impact. Chris acknowledges that developers often switch companies every few years, which might discourage them from investing deeply in a legacy codebase they won’t maintain long-term. Yet taking the lead in clarifying domain logic or reorganizing outdated sections is a skill-building opportunity. Future employers also notice engineers who can transform messy architectures into clear, future-friendly systems. In that sense, there’s a mutual benefit: the company gains maintainable software, while the developer acquires project leadership experience.

    The idea of “sitting in the problem space” resonates throughout Chris’s remarks. He encourages engineers to resist the reflex to propose solutions too early. Instead, they should keep asking why a particular annoyance or bug persists. Is it a symptom of a misaligned feature set, or is it rooted in limited domain knowledge among contributors? By reframing those frustrations as questions about responsibilities, the team often discovers simpler fixes than a heavy-handed rewrite. Conversely, where deeper rewrites are indeed warranted, Chris believes it’s best for the team to see that direction as unanimous rather than dictated from the top.

    Long-standing software also carries emotional baggage. People might have strong feelings about how something “ought” to be done, or they may have encountered recurring hurdles. Chris advocates using one-on-one conversations to let these concerns surface naturally, free from the pressure of group settings where quieter voices might hold back. Once everyone’s perspective is heard, common threads become clearer, enabling the team to converge on a smaller list of genuinely important tasks. When the group reconvenes, the sense of shared purpose helps unify efforts in a way that scattered brainstorming rarely achieves.

    The conversation also highlights resourceful domain modeling, which draws some inspiration from the microservices world but doesn’t necessarily require the code to be broken up into tiny services. Instead, Chris suggests that well-defined boundaries within a monolith can deliver comparable clarity—if the team respects those boundaries. He points to examples like Stripe or reading materials on Domain-Driven Design to show how cohesive object structures can help avoid big architectural hurdles.

    His closing thoughts revolve around long-term sustainability. Even if an engineer isn’t planning to remain on a project indefinitely, they can leave a meaningful legacy by clarifying crucial parts of the code, championing simpler naming conventions, and encouraging more open dialogue among team members. The impact, Chris notes, goes beyond the immediate project: every person who touches that code later benefits from these improvements, often for years to come.

    Time-Stamped Highlights

    [00:00:00] Welcome and Well-Maintained Software:
    Robby opens by asking Chris about foundational traits of dependable, long-lasting codebases.

    [00:00:58] Defining “Well Maintained”:
    They explore how clear conventions and minimal bloat not only reduce confusion but also prolong the life of a system.

    [00:01:28] LLMs and Context Windows:
    Chris delves into why large codebases challenge AI-driven coding assistants—and how trim, well-modeled systems sidestep this pitfall.

    [00:02:00] Joining Shopify and Facing Legacy Systems:
    Chris recalls his early days at Shopify, realizing that older Rails apps demanded a more structured method of discovery.

    [00:03:08] Concept of “Developer Paradise”:
    He shares his perspective on how removing unneeded documentation and extraneous complexity makes daily development more enjoyable.

    [00:05:32] Framework for Tackling Old Code:
    Chris outlines his signature approach: booking numerous 1-on-1 meetings to gather honest feedback from stakeholders before touching the code.

    [00:07:15] Finding High-Leverage Problems:
    Robby and Chris discuss distilling this feedback into a shortlist of real bottlenecks that the team can tackle together.

    [00:15:00] From Problem Space to Solutions:
    They spotlight the value of framing a single unifying question—like “How do we reduce confusion?”—to keep everyone working toward the same outcome.

    [00:20:07] Balancing Personal Goals and Company Needs:
    Chris underlines how aligning individual ambitions with business objectives fosters commitment to sustained improvement.

    [00:32:00] Long-Term Value and Leadership:
    Closing out, Robby and Chris consider how short-tenure engineers can leave a lasting impact by helping a team focus on its biggest pain points.

    Resources & Mentions

    • Shopify
    • Ruby on Rails
    • Chris’s GitHub
    • Chris’s LinkedIn
    • Chris’s Twitter/X
    • The One Thing by Gary Keller
    • Titan: The Life of John D. Rockefeller, Sr. by Ron Chernow
    • Martin Fowler on Microservices
    • Domain-Driven Design

    🍇 Thanks to Our Sponsor!

    Jelly is the simplest, most affordable way to deal with your “contact@...” emails.

    Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And Jelly is actually affordable —team-based pricing means everyone can pitch in with your team’s conversations with customers, clients, and beyond.

    Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable.

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

30. Heimir Thor Sverrisson: Architecture First, Tech Debt Second

    18 de marzo de 202541 minEpisodio 202A continuación

    Heimir Thor Sverrisson joins Robby to discuss the importance of software architecture in long-term maintainability. With over four decades in the industry, Heimir has witnessed firsthand how poor architectural …

    Notas del episodio

    Heimir Thor Sverrisson joins Robby to discuss the importance of software architecture in long-term maintainability. With over four decades in the industry, Heimir has witnessed firsthand how poor architectural decisions can set teams up for failure. He shares his experiences mentoring engineers, tackling technical debt, and solving large-scale performance problems—including one bank’s misguided attempt to fix system slowness by simply adding more CPUs.

    Heimir also discusses his work at MojoTech, the value of code reviews in consulting, and his volunteer efforts designing radiation-tolerant software for satellites.

    Episode Highlights

    • [00:01:12] Why architecture is the foundation of maintainability – Heimir explains why starting with the wrong architecture dooms software projects.
    • [00:02:20] Upfront design vs. agile methodologies – The tension between planning and iterative development.
    • [00:03:33] When architecture becomes the problem – How business pivots can render initial designs obsolete.
    • [00:05:06] The rising demand for rapid software delivery – Why modern projects have less time for deep architectural planning.
    • [00:06:15] Defining technical debt in practical terms – How to clean up code without waiting for permission.
    • [00:09:56] The rewrite that never launched – What happens when a company cancels a multi-million-dollar software project.
    • [00:12:43] How a major bank tackled system slowness the wrong way – Adding CPUs didn’t solve their performance problems.
    • [00:15:00] Performance tuning as an ongoing process – Why fixing one bottleneck only reveals the next.
    • [00:22:34] How MojoTech mentors instead of manages – Heimir explains how their consultancy approaches team development.
    • [00:27:54] Building software for space – How AMSAT develops radiation-resistant software for satellites.
    • [00:32:52] Staying relevant after four decades in tech – The power of curiosity in a constantly changing industry.
    • [00:34:26] How AI might (or might not) help maintainable software – Heimir shares his cautious optimism.
    • [00:37:14] Non-technical book recommendation – The Man Who Broke Capitalism and its relevance to the tech industry.

    Resources & Links

    • Heimir Thor Sverrisson on LinkedIn
    • Heimir’s GitHub
    • MojoTech
    • AMSAT – Amateur Radio Satellite Organization

    Book Recmmendations

    • The Man Who Broke Capitalism
    • How to Make Things Faster

    🍇 Thanks to Our Sponsor!

    Jelly is the simplest, most affordable way to deal with your “contact@...” emails.

    Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And Jelly is actually affordable —team-based pricing means everyone can pitch in with your team’s conversations with customers, clients, and beyond.

    Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable.

    💡 Enjoyed this episode? Share it with someone who cares about maintainable architecture and technical debt management!

    Every episode leaves good material on the cutting room floor. The Maintainable newsletter is where it goes, along with past episodes worth another listen. Join here: maintainable.fm/newsletter

Aquí están los 40 episodios más recientes de 236. Los anteriores están en el feed del podcast.