Maintainable

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 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 ValueKent 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” AgainRobby 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 FlexibilityThey 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 EasyKent 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 SawKent 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 TrapKent 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 ProblemRobby 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 TogetherKent describes why feature changes are irreversible, structure changes are reversible, and why combining them increases risk for everyone.[00:30:37] Tidying Reveals IntentWhile cleaning up structure, developers often uncover logic flaws or misunderstandings that were previously hidden.[00:32:00] When Teams Discourage TestingKent 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 ObligationKent 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 SlicingKent 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 TodayKent suggests adding a blank line to separate conceptual chunks in long functions. It is a small step that improves clarity immediately.Resources MentionedTidy First? by Kent BeckKent Beck on SubstackThe Timeless Way of Building by Christopher AlexanderThanks 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:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Don MacKinnon, a software engineer and founder of Searchcraft, discusses the importance of simplicity in software design. He shares a story about how an unnecessary abstraction in a Node.js API complicated development. Don explains how his team’s structure evolved from consulting pain points and emphasizes the value of clear project structure and documentation. He also advises on evaluating third-party libraries and uses real-world examples to illustrate the transition from dynamic languages to TypeScript and Rust for improved maintainability.

In this conversation, Chris Zetter, a software engineer and author focused on architecture and maintainability, shares insights about building relational databases. He emphasizes that effective software should enhance value and adaptability, often prioritizing solid documentation over code comments. Chris challenges the typical notions of technical debt, advocating for transparency about its causes. He also discusses the benefits of pairing in coding, especially for junior developers, and the value of choosing stable technology to improve reliability.

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 SoftwareDenis identifies consistency, documentation, testability, and agility as the key ingredients of maintainable systems.[00:02:22] Balancing Standards and AutonomyHow automation and linters help preserve code cohesion while minimizing interpersonal friction.[00:04:08] Experimenting SafelyElastic scopes new patterns to low-risk modules before broader adoption, avoiding mass rewrites.[00:07:19] Incremental CleanupLinters only apply to changed files, helping the team fix issues gradually without overwhelming contributors.[00:08:02] Maintainability as a People ProblemDenis highlights that sustainable systems depend more on culture and mentorship than on architecture.[00:10:13] Lessons from MiscommunicationAn early experience showed the cost of undocumented conventions and unclear onboarding.[00:17:09] Making Space for Technical DebtElastic’s engineers dedicate part of each sprint and an annual “On Week” to tackle maintenance work.[00:23:05] Restoring CI ReliabilityDenis 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 ArchaeologyHe stresses the value of documenting discussions in pull requests to avoid historical guesswork later.[00:36:09] Feedback and TrustOpen communication, humility, and mutual feedback loops form the backbone of a maintainable culture.[00:51:00] Embracing Chaos in Open SourceDenis encourages teams to accept a degree of entropy and focus their efforts on user-facing stability.[01:00:00] Security and PrivacyWhy maintainability, trust, and privacy are inseparable pillars of long-term sustainability.[01:01:06] Where to StartInstead of rewriting code, start by cultivating maintainability as a shared value across the team.Resources MentionedElasticgolangci-lintAppSignalThe 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.deDenis on GitHubDenis on MastodonDenis on LinkedInThanks 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:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

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 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 MentionedBrightworks 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! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Taylor Otwell, the creator of Laravel and CEO of Laravel LLC, shares his insights from 14 years of building one of the most popular web frameworks. He emphasizes simplicity and adaptability in software design, advocating for maintainability to prevent overcomplexity. Taylor recounts the early days of Laravel and the unexpected traction that transformed it into a full-time business. He discusses balancing community needs with his own preferences while navigating leadership challenges and community feedback, illustrating the evolving nature of both Laravel and his role within it.

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 & LinksSara on MastodonthoughtbotRubyConf 2024 Talk – Chaos Engineering on the Death StarBook: Being Wrong by Kathryn SchulzFlu Shot on GitHubChaosRB on GitHubSemian from Shopify — a chaos engineering toolkit for RubyThanks 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:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this discussion, Joel Chippindale, a seasoned CTO coach with over 20 years in software leadership, shares insights on creating sustainable software cultures. He emphasizes that maintainability hinges more on team communication and trust than on just clean code. Joel highlights real-world challenges like navigating technical debt, the pitfalls of pre-optimization, and the importance of strategic communication with stakeholders. He also offers practical advice for teams overwhelmed by legacy systems and advocates for focusing on present needs rather than uncertain future scenarios.

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 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.codesLinks and ResourcesMelanie's WebsiteHelios Design System at HashiCorpCradle Series by Will WightEmber Community SurveyA11y Automation GitHub ProjectAxe-coreFollow Melanie:GitHubLinkedInThanks 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:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

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 MaintainabilityJoe 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 CodebaseJoe outlines his ideal onboarding checklist and how he adapts to unfamiliar environments.[00:08:00] Setting Communication and Collaboration ExpectationsThe three questions Joe asks every client to understand how their team works.[00:13:02] Offering Opinions—Only Where InvitedWhy Joe stays scoped to the work he’s hired for, even when tempted to fix more.[00:14:15] When Technical Debt Enters the ConversationJoe explains how debt discussions usually emerge after version one is shipped.[00:15:33] Who Should Read Hotwire Native for Rails DevelopersJoe describes the type of developer his book is written for and what it covers.[00:18:01] Choosing Native vs. Hybrid for Your Rails AppA framework comparison based on your current frontend architecture.[00:20:00] Introducing the Hotwire Native MindsetWhy logic belongs on the server and the client should stay thin.[00:21:00] Bridge Components: How Rails, iOS, and Android ConnectJoe walks through how native and web technologies pass data between layers.[00:24:00] Why Even a Web View-Based App is Worth ShippingThe practical benefits of discoverability, push notifications, and native APIs.[00:28:01] Replacing Unmaintainable Apps with Hotwire NativeJoe describes how hybrid rewrites often reduce mobile code by 90%.[00:31:33] Letting Go of Feature ParityWhy most clients end up cutting features they originally wanted to preserve.[00:32:18] Scoping and Estimating Project-Based WorkHow Joe uses repeatable patterns to price fixed-fee consulting engagements.[00:35:15] Using AI to Translate Between Tech StacksJoe shares how he leverages LLMs to explore unfamiliar languages like Kotlin.[00:42:26] Long-Term Maintainability and When to Touch the CodeWhy some apps don’t need changes for years—and that’s okay.[00:43:43] Why Hybrid Apps Are Easier to ReplaceJoe explains why hybrid apps are often more disposable and less risky than monolithic web apps.🔗 Resources Mentioned:Joe’s Book: Hotwire Native for Rails DevelopersJoe’s NewsletterHotwire Native Mindset ArticlePlease Unsubscribe, Thanks by Julio Vincent GambutoFollow 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! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.