Maintainable

Taylor Otwell, creator of Laravel and CEO of Laravel LLC, joins Robby to reflect on his 14-year journey building and maintaining one of the most popular web frameworks in the world. From its PHP 5.3 origins to a full-time business with a 70-person team, Taylor shares what he's learned about code maintainability, developer experience, and what it means to evolve without overcomplicating things.He discusses the importance of simplicity in software design, why sticking to framework conventions leads to better long-term outcomes, and how his minimalist mindset continues to shape Laravel today. Taylor also opens up about the moment he felt out of ideas, how Laravel’s 2024 funding round marked a new chapter, and what it’s like to hand off more responsibility while staying involved in the open source core.Episode Highlights[00:01:07] Taylor’s Definition of Maintainable Software  Simplicity, understandability, and confidence in making changes are key themes in Taylor's approach to longevity in software.[00:02:13] Ken

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 documentati

CTO coach Joel Chippindale joins Robby to share what he's learned over two decades of building and leading software teams. Joel argues that maintainability has less to do with “clean code” and more to do with how teams communicate, prioritize, and make progress visible. Drawing on his time at Unmade and his current coaching practice, Joel outlines practical ways teams can build trust, navigate brittle systems, and stop letting technical debt conversations get lost in translation.Episode Highlights[00:01:10] A Working Definition of MaintainabilityJoel explains why “software that’s easy to keep changing” is the gold standard—and why context matters as much as code.[00:05:24] The Pitfalls of Pre-OptimizationHow developers can trap themselves by designing for futures that may never arrive.[00:10:40] Challenging the Iron TriangleJoel pushes back on the idea that teams must sacrifice quality for speed or cost.[00:15:31] Quality Is a Team ConversationWhy code quality starts long before you open your editor.[00:20:00

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-Maint

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

Freedom Dumlao (CTO at Vestmark) joins Robby to explore what it means to maintain software at scale—and why teams sometimes need to unlearn the hype.With two decades of experience supporting financial systems, Freedom shares how his team manages a Java monolith that oversees $1.6 trillion in assets. But what’s most surprising? His story of how a team working on 70+ microservices rebuilt their platform as a single Ruby on Rails monolith—and started shipping faster than ever before.Episode Highlights[00:02:00] Why Respecting Legacy Code MattersFreedom reflects on a lesson he learned at Amazon: "Respect what came before." He discusses the value of honoring the decisions of past developers—especially when their context is unknown.[00:05:00] How Tests Help (and Where They Don’t)Freedom discusses how tests can clarify system behavior but not always intent—especially when market logic or business-specific rules come into play.[00:07:00] The Value of Understudies in EngineeringFreedom shares how his team intentionall

Mercedes Bernard, Staff Software Engineer at Kit, joins Robby to talk about what it really means to write code that lasts—and who it should be written for.In this episode of Maintainable, Mercedes shares a thoughtful and practical perspective on working with legacy codebases, managing technical debt, and creating a team culture that values maintainability without fear or shame. Her guiding principle? Well-maintained software is friendly software—code that is understandable and approachable, especially for early-career developers.Together, they discuss how to audit and stabilize older systems, avoid full rewrites, and create consistent developer experiences in large applications. Mercedes reflects on her decade in consulting and how that shaped her approach to navigating incomplete documentation, missing historical context, and multiple competing patterns in a codebase. She breaks down different types of technical debt, explains why not all of it is inherently bad, and offers strategies for advocating for main

Evan Phoenix (@evanphx), CEO of Miren, joins Robby to explore the subtle but powerful difference between writing code that works and writing code that explains itself. They discuss the role of clarity in maintainable systems, why splitting a monolith can backfire, and what developers can learn from artists and tradespeople alike.Episode Highlights[00:01:30] What Makes Software Maintainable?Evan defines maintainability as how easily a newcomer can make a change with minimal context.[00:02:30] Why Business Logic Should Be ObviousA discussion on domain knowledge leakage and abstracting rules like “can we sell today?”[00:05:00] Programming 'Mouthfeel' and the Trap of PrefactoringEvan explains why prematurely optimizing for reuse can lead to unnecessary complexity.[00:07:00] When to Extract Logic: The Copy/Paste SignalA practical approach to identifying reusable components by spotting repeated code.[00:08:00] Technical Debt as a Reflection of Cognitive LoadWhy forgetting your own code doesn’t automatically mean it

Software isn’t always about rapid iteration. Sometimes, the real challenge lies in carefully assessing the existing environment. Chris Salvato, a Senior Staff Engineer at Shopify, believes that spending time in the “problem space” is vital for any long-lived application. Rather than diving immediately into controllers and tests, he begins by talking to everyone who interacts with the code—engineers, product owners, even directors who oversee strategy. This approach reveals hidden friction points that rarely come to light in larger, more formal meetings.When code grows organically over years, a range of issues emerges. Small workarounds might accumulate, new features can overlap with older ones, and domain boundaries become murky. Chris suggests mapping these overlaps through in-depth conversations so the team can pinpoint what genuinely obstructs productivity. He emphasizes that many developers may focus on surface fixes—updating a library here, renaming a class there—without acknowledging underlying confusio

Heimir Thor Sverrisson joins Robby to discuss the importance of software architecture in long-term maintainability. With over four decades in the industry, Heimir has witnessed firsthand how poor architectural decisions can set teams up for failure. He shares his experiences mentoring engineers, tackling technical debt, and solving large-scale performance problems—including one bank’s misguided attempt to fix system slowness by simply adding more CPUs.Heimir also discusses his work at MojoTech, the value of code reviews in consulting, and his volunteer efforts designing radiation-tolerant software for satellites.Episode Highlights[00:01:12] Why architecture is the foundation of maintainability – Heimir explains why starting with the wrong architecture dooms software projects.[00:02:20] Upfront design vs. agile methodologies – The tension between planning and iterative development.[00:03:33] When architecture becomes the problem – How business pivots can render initial designs obsolete.[00:05:06] The rising de

Not every messy piece of code needs a refactor. Noémi Ványi, Senior Software Engineer at Xata, joins Robby to discuss how to develop the intuition to know when refactoring is truly necessary and when it’s just unnecessary churn. She shares her approach to balancing pragmatism and maintainability, how product teams and developers can work better together, and why developer autonomy is key to sustainable software.Drawing from her experience working on both open-source and closed-source projects, Noémi reflects on the unique challenges each presents—whether it's dealing with unresponsive GitHub issue reporters, handling unanticipated user behaviors, or navigating large-scale refactors in existing systems. She also shares her philosophy on technical debt: not all of it needs to be paid down, and some of it can actually be strategic.Robby and Noémi also explore the importance of writing meaningful commit messages, the hidden benefits of reviewing open-source pull requests, and why developers should stop waiting fo

How much can legacy code tell us beyond just functionality? Julia López, Senior Software Engineer at Harvest, believes that even small details—such as white spaces, variable names, and formatting choices—can reveal a system’s history.In this episode, Julia and Robby discuss the importance of refactoring and how a strong engineering culture can make or break a team's ability to maintain and improve software over time. Julia shares her experience leading a multi-year overhaul of Harvest’s billing system, balancing stakeholder expectations while ensuring the rewrite delivered real value.They explore how refactoring decisions evolve as teams grow, how to mentor newer developers to feel empowered to make changes, and why Julia doesn’t always trust her own estimations (for good reason). She also opens up about the complexities of transitioning a live billing system while supporting customers, finance teams, and engineering operations—all without disrupting payments.Beyond technical decisions, they also dive into th

Episode OverviewMarty Haught joins Robby to discuss the sustainability of open-source projects, the challenges of maintaining RubyGems, and why the metaphor of technical debt may not fully capture how software ages. Instead, he suggests thinking of it as drift—the natural misalignment of software with its evolving purpose over time.They also dig into security challenges in package management, including how Ruby Central worked with Trail of Bits to audit RubyGems. Marty also shares insights on the EU Cyber Resilience Act and how it might affect open-source maintainers worldwide. Finally, they explore how companies can support open-source sustainability through corporate sponsorships and individual contributions.Topics Discussed[00:01:00] The two pillars of maintainable software: good tests and readability.[00:02:40] From Perl to Ruby: How readability changed Marty's approach to programming.[00:07:20] Is technical debt the right metaphor? Why "drift" might be a better fit.[00:11:00] What does it take to maintai

Mike Bowers, Chief Architect at FairCom, has spent decades navigating the evolution of database technology. In this conversation, he and Robby explore the challenges of maintaining a 40+ year-old codebase, balancing legacy constraints with forward-thinking design, and the realities of technical debt.Mike shares how FairCom transitioned from ISAM-based databases to modern JSON-driven APIs, the trade-offs between strict schemas and flexible document stores, and how software architecture plays a critical role in long-term maintainability. He also explains why human-readable JSON simplifies debugging, how documentation-driven development improves API usability, and why many software teams struggle with refactoring at the right time.Topics covered[00:05:32] The role of software architecture in long-term maintainability[00:10:45] Why FairCom's legacy ISAM technology still matters today[00:14:20] Transitioning to a JSON-based API for modern developers[00:19:40] The challenges of maintaining 40+ years of C code[00:24

Join Robby as he chats with Lorna Mitchell, open source advocate and technical writer, about the art of creating documentation that doesn’t gather dust. Lorna shares her experiences as a maintainer of the open source project RST2PDF, the value of API governance, and how documentation bridges gaps in developer experience.Highlights:What Makes Software Maintainable: Characteristics like great documentation, automated tests, and onboarding ease.Documentation's Role in Long-Lived Software: Why it’s crucial for internal tools and open source projects alike.Open Source in Practice: Lorna’s journey with RST2PDF and adopting a tech stack she wasn’t initially fluent in.API Governance Simplified: Lorna explains the four levels of API readiness and how teams can work toward more usable APIs.Writing Documentation for Engineers: How style guides can empower contributors without overwhelming them.Using Tools to Improve Documentation: From linters to prose-checking tools like Veil, Lorna discusses practical tips.Key Takeawa

Episode SummaryIn this episode of Maintainable, Robby sits down with Carola Lilienthal, Software Architect and Managing Director at WPS. Together, they explore the intersection of cognitive science and software architecture, strategies for tackling technical debt, and why simplicity, modularity, and domain knowledge are crucial for maintainability.Carola shares her approach to improving legacy systems, fostering domain-driven development, and introducing sustainable patterns into software design. She also discusses the Modularity Maturity Index (MMI), a tool her team has used to assess and improve over 300 systems.Topics Covered[00:00:43] What makes software maintainable?[00:01:24] The importance of clear structure, modularity, and simplicity in software.[00:02:38] How patterns help reduce complexity and onboard developers faster.[00:04:42] Addressing the challenges of systems with mixed architectural patterns.[00:06:20] Strategies for fostering creativity while maintaining simplicity.[00:07:05] How to guide

Topics DiscussedThe importance of changeability as a core characteristic of well-maintained software.How GitHub has approached accessibility as a business and legal imperative.The evolution of GitHub’s frontend system, spanning over 2,000 pages, and the concept of "frontend vintages."Primer: GitHub’s design system and the paradox of its success—consistency vs. changeability.The disproportionate maintenance costs of frontend systems compared to backend systems.Using tools like Axe and keyboard-only tests to identify and resolve accessibility issues.The philosophical balance between creativity and usability in software design.Practical advice for teams starting their accessibility journey with limited resources.How frontend complexity affects scalability, especially in app-like experiences.Joel’s advocacy for adopting off-the-shelf components to reduce complexity for smaller teams.Key Takeaways[00:01:12] What Defines Well-Maintained Software?Joel explains how changeability—the confidence to make and deploy chan

Austin Story, Senior Engineering Director at Doximity, joins Robby to explore the intricacies of building maintainable systems, fostering team accountability, and enabling faster iteration without sacrificing quality. Austin shares how his team approached migrating from a monolithic GraphQL architecture to a federated model, why simplicity matters for long-term success, and how guiding principles like YAGNI influence his decision-making.Doximity is a leading digital platform for medical professionals, and their technology blog offers deep dives into the systems and tools that power their innovative solutions.Key Topics Discussed[00:00:41] What is maintainable software? Austin highlights key traits, including testability, simplicity, and ease of removal.[00:02:09] Designing for removability: Why it's important and how it enables iterative progress.[00:03:05] YAGNI (You Aren’t Gonna Need It): How this principle shapes Austin's approach to feature development.[00:04:13] Migrating to GraphQL Federation: Benefits

Topics CoveredCharacteristics of Maintainable SoftwareDan emphasizes the importance of internal consistency in codebases, automated tests, and proper documentation to preserve decision-making context.[00:05:32] Internal consistency: Why it matters.[00:08:09] Lessons from maintaining legacy codebases.Working with Legacy SystemsDan shares stories of upgrading ORM frameworks, introducing caching systems, and transitioning to bug tracking tools.[00:09:52] Replacing custom ORM systems with Hibernate and Ehcache.[00:13:10] Tackling high-risk components with automated testing.Modern Authentication ChallengesAs part of FusionAuth, Dan discusses building developer-friendly tools that balance local flexibility with SaaS convenience.[00:21:05] FusionAuth’s role in secure authentication.[00:28:13] Testing authentication flows locally and in CI pipelines.Navigating Constraints in TeamsAdvice for managing technical debt, advocating for team priorities, and communicating with stakeholders during lean times.[00:16:39] Commun

In this episode of Maintainable, Robby speaks with Tom Johnson, Co-Founder and CEO of Multiplayer. Tom shares his perspectives on the evolving landscape of distributed systems, the challenges of maintaining legacy software, and how innovative tools are transforming the way teams collaborate.Topics DiscussedCharacteristics of well-maintained software, from system-level documentation to effective workflows.The importance of debugging tools tailored for distributed systems.Anecdotes about managing technical debt, including cutting off a CEO’s database access.How auto-documentation and design branches in Multiplayer streamline team collaboration.Practical strategies for tackling technical debt and fostering developer morale.Key Takeaways[00:01:16] Defining Well-Maintained Software: Tom explains why documentation, tests, and collaborative workflows are essential.[00:06:14] The Case for Locking Down Production: Lessons learned from a humorous but cautionary tale.[00:18:11] Debugging Distributed Systems: How Multipl