• 55 minutes 1 second
    David Hayes: Boring Software, Clear Incentives, and Better Checklists

    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

    Book Recommendations

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    18 August 2026, 7:00 am
  • 48 minutes 56 seconds
    Diana Pfeil: Building Confidence in Probabilistic Systems

    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

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    4 August 2026, 7:00 am
  • 54 minutes 30 seconds
    Chris Coyier: The Long Game of Maintaining CodePen

    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

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    16 June 2026, 7:00 am
  • 55 minutes 34 seconds
    Sally Lait: Confidence Is the Real Metric

    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

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    5 May 2026, 7:00 am
  • 55 minutes 26 seconds
    Rein Henrichs: The Real Work of Maintenance Happens Before You Touch the Code

    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

    Concepts & References

    Referenced in this Conversation

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    14 April 2026, 7:00 am
  • 54 minutes 40 seconds
    Russ Olsen: The Hidden Cost of Forgetting Why the Code Looks Like That

    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

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    31 March 2026, 7:00 am
  • 1 hour 1 minute
    Joel Oliveira: Predictability Is a Maintainability Feature

    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

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    17 March 2026, 7:00 am
  • 54 minutes 21 seconds
    Lucas Roesler: The Fast Feedback Loop Advantage

    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 & References

    Guest and Company

    Social

    Books Mentioned

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    3 February 2026, 8:00 am
  • 1 hour 36 seconds
    Brittany Ellich: Using AI to Maintain Software, Not Rewrite It

    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

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    21 January 2026, 8:00 am
  • 49 minutes 31 seconds
    Kent L Beck: You’re Ignoring Optionality… and Paying for It

    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

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    9 December 2025, 8:00 am
  • 50 minutes 31 seconds
    Don MacKinnon: Why Simplicity Beats Cleverness in Software Design

    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

    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!

    Subscribe to Maintainable on:

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.

    2 December 2025, 8:00 am
  • More Episodes? Get the App