Maintainable

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 intentionally pairs subject matter experts with understudies to reduce risk and transfer knowledge.[00:09:30] Rethinking Technical DebtHe challenges the fear-based framing of technical debt, comparing it instead to a strategic mortgage.[00:17:00] From 70 Services to 1 MonolithAt FlexCar, Freedom led an unconventional rewrite—consolidating 70 Java microservices into a single Rails app. The result? A dramatic increase in velocity and ownership.[00:25:00] Choosing Rails Over Phoenix, Laravel, and DjangoAfter evaluating multiple frameworks, Rails' cohesiveness, Hotwire, and quick developer ramp-up made it the clear winner—even converting skeptical team members.[00:31:00] How Rails Changed Team DynamicsBy reducing dependency handoffs, the new Rails app enabled solo engineers to own complete features. The impact? Faster delivery and more engaged developers.[00:36:30] Why Rails Still Makes Sense at a 20-Year-Old CompanyEven with a large Java codebase, Vestmark uses Rails for rapid prototyping and new product development.[00:41:00] Using AI to Navigate Legacy SystemsFreedom explains how his team uses retrieval-augmented generation (RAG) to surface relevant code—but also the limitations of AI on older or less common codebases.[00:51:00] Seek Feedback, Not ConsensusFreedom explains why aiming for alignment slows teams down—and how decision-makers can be inclusive without waiting for full agreement.Links and ResourcesFreedom Dumlao on LinkedInVestmarkNo Rules RulesDungeon Crawler Carl seriesThanks 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.

Mercedes Bernard, Staff Software Engineer at Kit, joins Robby to talk about what it really means to write code that lasts—and who it should be written for.In this episode of Maintainable, Mercedes shares a thoughtful and practical perspective on working with legacy codebases, managing technical debt, and creating a team culture that values maintainability without fear or shame. Her guiding principle? Well-maintained software is friendly software—code that is understandable and approachable, especially for early-career developers.Together, they discuss how to audit and stabilize older systems, avoid full rewrites, and create consistent developer experiences in large applications. Mercedes reflects on her decade in consulting and how that shaped her approach to navigating incomplete documentation, missing historical context, and multiple competing patterns in a codebase. She breaks down different types of technical debt, explains why not all of it is inherently bad, and offers strategies for advocating for maintenance work across engineering and product teams.The conversation also touches on architecture patterns like job fan-out, measuring performance regressions, reducing infrastructure load, and building momentum for improvements even when leadership isn’t actively prioritizing them.If you’ve ever felt overwhelmed by a messy project or struggled to justify maintenance work, this episode will leave you with a fresh mindset—and a few practical tactics—for making code more sustainable and inclusive.Episode Highlights[00:01:08] Defining Well-Maintained SoftwareMercedes explains her top metric: software that feels friendly, especially to early-career developers navigating the codebase for the first time.[00:03:00] What Friendly Code Actually Looks LikeShe shares why consistency, discoverability, and light documentation (like class comments or UML snippets) can make a huge difference.[00:05:00] Assessing Code Like a House TourMercedes introduces her metaphor of giving a house tour to evaluate code: does everything feel like it’s in the right place—or is the stove in the cabinet?[00:06:53] Consulting Mindset: Being a Guest in the CodebaseWith a decade of consulting experience, Mercedes shares how she navigates legacy systems when historical context is long gone.[00:10:40] Stabilizing a Startup’s Tangled ArchitectureShe walks through an in-depth case study where she helped a client with multiple abandoned services get back to stability—without a rewrite.[00:17:00] The Power of a One-Line FixMercedes shares how a missing check caused a job to fan out 30 million no-op background jobs a day—and how one line of code reduced that by 75%.[00:23:40] Why State Checks Belong EverywhereShe explains how defense-in-depth patterns help avoid job queue flooding and protect system resources early in the fan-out process.[00:24:59] Reframing Technical DebtNot all debt is bad. Mercedes outlines three types—intentional, evolutionary, and time-based—and how to approach each one differently.[00:28:00] Why Teams Fall Behind Without Realizing ItMercedes and Robby talk about communication gaps between engineers and product stakeholders—and why it’s not always clear when tech debt starts piling up.[00:34:00] Quantifying Developer FrictionMercedes recommends expressing technical debt in terms of lost time, slow features, and increased cost rather than vague frustrations.[00:42:00] Getting Momentum Without PermissionHer advice to individual contributors: start small. Break down your frustrations into bite-sized RFCs or tickets and show the impact.[00:45:40] Letting the Team Drive StandardsMercedes encourages team-led conventions over top-down declarations, and explains why having any decision is better than indecision.[00:47:54] Recommended ReadingShe shares a surprising favorite: The Secret Life of Groceries, a systems-thinking deep dive into the grocery industry by Benjamin Lorr.Resources & Links🧠 Mercedes Bernard’s website🛠 Kit📘 The Secret Life of Groceries by Benjamin Lorr🔎 Fan-out Pattern – Martin Fowler (for deeper context on fan-out job strategies)💬 Mercedes on 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.

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’s “bad” code.[00:10:30] Testing as Emotional InsuranceHow writing even basic checks can build team confidence—especially when test coverage is weak.[00:13:00] Daily Integration Tests: A Low-Pressure Safety NetUsing nightly integration runs to catch invisible bugs in complex systems.[00:14:00] Confidence > 100% Test CoverageWhy fast feedback loops matter more than aiming for exhaustive tests.[00:20:00] Splitting the Monolith: A Cautionary TaleEvan shares how decoupling apps without decoupling the database created chaos.[00:22:00] Shared Models, Split Repos, and Hidden PitfallsThe unexpected bugs that emerge when two apps maintain duplicate models and validations.[00:23:00] Better Alternatives to Splitting CodebasesHow separate deployments and tooling can mimic team separation without architectural debt.[00:28:00] The Hidden Cost of Diverging Business DomainsWhen apps evolve independently, business logic begins to drift—undermining consistency.[00:29:00] Building Miren and Staying MotivatedHow Evan approaches early-stage product development with curiosity and detachment.[00:36:00] How to Know When Your Open Source Project Is “Done”Reframing “dead” projects as complete—and why stability is often a feature.[01:01:00] Signals for Trusting Open Source DependenciesEvan’s mental checklist for evaluating if a library is worth adopting.[01:07:00] The Importance of Hiring Junior DevelopersWhy investing in beginners is crucial for the future of our industry.[01:08:00] Book RecommendationsEvan recommends The Inner Game of Tennis and Snow Crash.Links and ResourcesEvan Phoenix’s WebsiteEvan on GitHubEvan on MastodonBook RecommendationsThe Inner Game of Tennis (book)Snow Crash by Neal StephensonThanks 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.

Chris Salvato, a Senior Staff Engineer at Shopify, shares invaluable insights into navigating legacy codebases. He emphasizes the importance of understanding human frustrations and spending time in the 'problem space' instead of rushing to fix issues. By focusing on one-on-one conversations, Chris helps teams identify systemic pain points and align their goals. He highlights the need for lean and intuitive domain models, effective team collaboration, and the role of mentorship in software development, transforming challenges into opportunities for growth.

Heimir Thor Sverrisson, an engineering mentor at MojoTech with over 40 years in software development, dives deep into the critical role of software architecture. He discusses how poor architectural choices lead to failure and shares experiences from mentoring engineers and tackling technical debt. Heimer highlights a major bank's misguided performance fix, emphasizing the importance of upfront design versus agile practices. He also touches on the balance between rapid delivery and thorough planning, and his volunteer work in satellite software design.

Noémi Ványi, a Senior Software Engineer at Xata, discusses the art of knowing when to refactor code and the importance of developer autonomy for sustainable software. She shares insights on balancing pragmatism with maintainability and reflects on her experiences with both open-source and closed-source projects. Noémi emphasizes that not all technical debt needs addressing, advocating for strategic management instead. The conversation also touches on the significance of strong communication in teams and the necessity of clear commit messages to enhance collaboration.

Join Julia López, a Senior Software Engineer at Harvest, as she shares her passion for code refactoring and the significance of white spaces and variable names in understanding legacy systems. Julia discusses her experience revamping Harvest's billing system, balancing stakeholder expectations, and the challenges of transitioning while supporting various teams. She emphasizes the importance of mentorship in navigating refactoring, communication in remote settings, and strategies for advocating technical debt reduction, making for insightful takeaways.

Marty Haught, Director of Open Source at Ruby Central, talks about the sustainability challenges of open-source projects and the unique responsibilities of maintaining RubyGems. He proposes that ‘drift’ may be a more accurate metaphor than technical debt for the aging of software. The discussion highlights security strategies, including a partnership with Trail of Bits for auditing, and examines the implications of the EU Cyber Resilience Act on maintainers. Haught emphasizes the importance of corporate sponsorships in supporting open-source sustainability.

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:10] Technical debt: What it really means and how to manage it[00:28:50] The trade-offs between strict schemas and flexible NoSQL approaches[00:34:00] When to refactor vs. when to start over from scratch[00:38:15] The influence of product management thinking on software architecture[00:42:30] Advice for engineers considering a shift into architecture rolesResources MentionedFairComMike Bowers on LinkedInFairCom on Twitter/XBook Recommendation:The Influential Product Manager by MSc BuceroThanks to Our Sponsor!Need a smoother way to share your team's inbox? Jelly’s got you covered! 🍇✨Jelly is perfect for small teams — because it was built by a small team. If you struggle with keeping your team’s knowledge organized and accessible, check out Jelly, a lightweight knowledge management tool designed to make finding answers easy—without all the clutter of traditional wikis. No more sticky situations or knowledge gaps—Jelly keeps everything smooth, and shareable.Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable, 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.

Lorna Mitchell, an open source advocate and technical writer, shares her expertise on creating documentation that engineers actually read. She discusses the vital role of documentation in software maintainability and the challenges of reviving old projects like RST2PDF. Lorna emphasizes API governance and introduces four levels of API readiness to enhance usability. Additionally, she shares practical tips for improving technical writing using tools and strategies that make complex information accessible and relatable for developers.