Maintainable

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 & ResourcesMark Stringer's websiteMark Stringer on LinkedInDelivering the Impossible: Successful Ways of Seeing Software Project Management by Mark StringerThinking, Fast and Slow by Daniel KahnemanKeith JohnstoneEdinburgh 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

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 & LinksQuint Quint on GitHubTowards a Solution for Cognitive DebtQuint Connect and the Emerald projectTLA+OpenHandsGabriela Moreira on LinkedInGabriela's interview with Unite.AIThe Name of the Wind by Patrick RothfussOpenHands Kubernetes Use CaseTrying out Quint: 5-min getting startedSign 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

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 & ResourcesWaspWasp on GitHubA New Language for Web Dev Was a MistakeMatija Šošić on XMatija Šošić on LinkedInZen and the Art of Motorcycle MaintenanceRuby on RailsLaravelPrisma 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

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 LinksElixirDashbitTidewavePhoenix FrameworkErlangHexHexDocsNumerical ElixirNxFoundation by Isaac AsimovDune 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

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 & ResourcesJohn AthaydeMeticulousJohn Athayde on LinkedInJohn Athayde on BlueskyJohn Athayde on XJohn Athayde on Ruby SocialThe Timeless Way of Building by Christopher AlexanderA Pattern Language by Christopher Alexander, Sara Ishikawa, and Murray SilversteinThe Phoenix Architecture by Chad FowlerRuby on RailsAxe-coreHerb, 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