Episodios

  • Joel Chippindale: Why High-Quality Software Isn’t About Developer Skill Alone

    Joel Chippindale: Why High-Quality Software Isn’t About Developer Skill Alone
    Jul 1 2025

    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 Maintainability
    Joel 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-Optimization
    How developers can trap themselves by designing for futures that may never arrive.

    [00:10:40] Challenging the Iron Triangle
    Joel pushes back on the idea that teams must sacrifice quality for speed or cost.

    [00:15:31] Quality Is a Team Conversation
    Why code quality starts long before you open your editor.

    [00:20:00] Unmade Case Study: From Chaos to Confidence
    How Joel helped a struggling team at Unmade regain trust by delivering less—and showing more.

    [00:28:08] Helping Business Stakeholders Buy Into Maintenance Work
    How to reframe backend investments in terms that resonate across departments.

    [00:33:40] First Steps for Fragile Systems
    What Joel looks for when coaching teams overwhelmed by legacy code.

    [00:41:32] The Value of Boring Technology
    Why solving real problems matters more than chasing resume polish.

    [00:45:20] The Case for Coaching
    What makes leadership coaching valuable—and why it's not a sign of weakness.

    [00:51:10] Building Your Manager Voltron
    Joel shares why every developer should cultivate their own support system, including mentors, peers, and coaches.

    Resources & Mentions
    • Joel’s Coaching Site – Monkey’s Thumb
    • Joel on Mastodon
    • “Take Back Control of Code Quality” – Joel’s Blog Post
    • “Manager Voltron” by Lara Hogan
    • Never Split the Difference by Chris Voss
    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 Podcasts
    • Spotify

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.
    Más Menos
    57 m
  • Melanie Sumner: Why Continuous Accessibility Is a Strategic Advantage

    Melanie Sumner: Why Continuous Accessibility Is a Strategic Advantage
    Jun 10 2025
    Melanie Sumner: Why Continuous Accessibility Is a Strategic Advantage

    Melanie 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.codes

    Links and Resources
    • Melanie's Website
    • Helios Design System at HashiCorp
    • Cradle Series by Will Wight
    • Ember Community Survey
    • A11y Automation GitHub Project
    • Axe-core

    Follow Melanie:

    • GitHub
    • LinkedIn
    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 Podcasts
    • Spotify

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.
    Más Menos
    50 m
  • Joe Masilotti: Simplify Your Stack, Ship Mobile Sooner

    Joe Masilotti: Simplify Your Stack, Ship Mobile Sooner
    May 20 2025
    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.
    Más Menos
    56 m
  • Freedom Dumlao: What 70 Java Services Taught Me About Focus

    Freedom Dumlao: What 70 Java Services Taught Me About Focus
    Apr 22 2025

    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 Matters
    Freedom 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 Engineering
    Freedom shares how his team intentionally pairs subject matter experts with understudies to reduce risk and transfer knowledge.

    [00:09:30] Rethinking Technical Debt
    He challenges the fear-based framing of technical debt, comparing it instead to a strategic mortgage.

    [00:17:00] From 70 Services to 1 Monolith
    At 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 Django
    After 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 Dynamics
    By 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 Company
    Even with a large Java codebase, Vestmark uses Rails for rapid prototyping and new product development.

    [00:41:00] Using AI to Navigate Legacy Systems
    Freedom 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 Consensus
    Freedom explains why aiming for alignment slows teams down—and how decision-makers can be inclusive without waiting for full agreement.

    Links and Resources
    • Freedom Dumlao on LinkedIn
    • Vestmark
    • No Rules Rules
    • Dungeon Crawler Carl series
    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 Podcasts
    • Spotify

    Or search "Maintainable" wherever you stream your podcasts.

    Keep up to date with the Maintainable Podcast by joining the newsletter.
    Más Menos
    1 h y 3 m
  • Mercedes Bernard: Friendly Code Welcomes Everyone In

    Mercedes Bernard: Friendly Code Welcomes Everyone In
    Apr 8 2025
    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.
    Más Menos
    49 m
  • Evan Phoenix: The Why of the One Line

    Evan Phoenix: The Why of the One Line
    Apr 1 2025
    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.
    Más Menos
    1 h y 9 m
  • Chris Salvato: Building Developer Paradise by Sitting in the Problem Space

    Chris Salvato: Building Developer Paradise by Sitting in the Problem Space
    Mar 25 2025
    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 confusion in the domain model itself. Removing extraneous code, clarifying domain entities, and aligning the team’s understanding can drastically reduce missteps.An interesting aspect of Chris’s method is his view of “developer paradise.” A codebase reaches this state when new contributors can navigate it with minimal help. Instead of sifting through endless documentation or complex wikis, they can figure out how classes, modules, and services connect simply by reading the code. Chris notes that achieving this often involves pruning unnecessary files or responsibilities. The end result is software that “self-documents,” easing onboarding and reducing reliance on external explanations.The conversation also touches on how large language models (LLMs) fit into the puzzle. Many organizations see AI-driven coding assistants as a way to accelerate development. Chris agrees they have potential, yet highlights a critical requirement: the code must be well-organized. If the system is sprawling and inconsistent, these tools may only add confusion. Lean, carefully segmented projects let both people and AI more effectively track what’s happening under the hood.Reducing code bloat leads naturally to discussions about prioritizing. Chris encourages teams not to tackle every annoyance at once. He references the importance of framing a unifying question, such as “Which feature or aspect of the app causes the greatest confusion among team members?” Spending too little time on this question, he warns, results in half-hearted improvements that eventually revert back to chaos. By contrast, devoting a few dedicated sprints—guided by thoughtful one-on-one interviews—can create lasting changes that set the entire codebase on a better trajectory.One intriguing theme is how personal growth ties into organizational impact. Chris acknowledges that developers often switch companies every few years, which might discourage them from investing deeply in a legacy codebase they won’t maintain long-term. Yet taking the lead in clarifying domain logic or reorganizing outdated sections is a skill-building opportunity. Future employers also notice engineers who can transform messy architectures into clear, future-friendly systems. In that sense, there’s a mutual benefit: the company gains maintainable software, while the developer acquires project leadership experience.The idea of “sitting in the problem space” resonates throughout Chris’s remarks. He encourages engineers to resist the reflex to propose solutions too early. Instead, they should keep asking why a particular annoyance or bug persists. Is it a symptom of a misaligned feature set, or is it rooted in limited domain knowledge among contributors? By reframing those frustrations as questions about responsibilities, the team often discovers simpler fixes than a heavy-handed rewrite. Conversely, where deeper rewrites are indeed warranted, Chris believes it’s best for the team to see that direction as unanimous rather than dictated from the top.Long-standing software also carries emotional baggage. People might have strong feelings about how something “ought” to be done, or they may have encountered recurring hurdles. Chris advocates using one-on-one conversations to let these concerns surface naturally, free from the pressure of group settings where quieter voices might hold back. Once everyone’s perspective is heard, common threads become clearer, enabling the team to converge on a smaller list of genuinely important tasks. When the group reconvenes, the sense of shared purpose helps unify efforts in a way that scattered brainstorming rarely achieves.The conversation also highlights resourceful domain modeling, which draws some inspiration from the microservices world but doesn’t necessarily require the code to be broken up into tiny services. Instead, Chris suggests that well-defined boundaries within a monolith can deliver ...
    Más Menos
    47 m
  • Heimir Thor Sverrisson: Architecture First, Tech Debt Second

    Heimir Thor Sverrisson: Architecture First, Tech Debt Second
    Mar 18 2025
    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 demand for rapid software delivery – Why modern projects have less time for deep architectural planning.[00:06:15] Defining technical debt in practical terms – How to clean up code without waiting for permission.[00:09:56] The rewrite that never launched – What happens when a company cancels a multi-million-dollar software project.[00:12:43] How a major bank tackled system slowness the wrong way – Adding CPUs didn’t solve their performance problems.[00:15:00] Performance tuning as an ongoing process – Why fixing one bottleneck only reveals the next.[00:22:34] How MojoTech mentors instead of manages – Heimir explains how their consultancy approaches team development.[00:27:54] Building software for space – How AMSAT develops radiation-resistant software for satellites.[00:32:52] Staying relevant after four decades in tech – The power of curiosity in a constantly changing industry.[00:34:26] How AI might (or might not) help maintainable software – Heimir shares his cautious optimism.[00:37:14] Non-technical book recommendation – The Man Who Broke Capitalism and its relevance to the tech industry.Resources & LinksHeimir Thor Sverrisson on LinkedInHeimir’s GitHubMojoTechAMSAT – Amateur Radio Satellite OrganizationBook RecmmendationsThe Man Who Broke CapitalismHow to Make Things Faster🍇 Thanks to Our Sponsor!Jelly is the simplest, most affordable way to deal with your “contact@...” emails.Tired of sharing an email login, or CCing colleagues to loop them into conversations? Terrified by the dizzying total cost of big-name “customer support” tools? Jelly is the answer. Whether it's for customer support, community organizing, or even managing band emails, Jelly helps your team share an email inbox and manage your conversations in a simple, elegant way. Use the "I got this” feature to communicate responsibility and private comments for internal discussions. Jelly is perfect for small teams — because it was built by a small team. And Jelly is actually affordable —team-based pricing means everyone can pitch in with your team’s conversations with customers, clients, and beyond.Bonus for Maintainable listeners Get 20% off your first year at letsjelly.com/maintainable.💡 Enjoyed this episode? Share it with someone who cares about maintainable architecture and technical debt management! 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.
    Más Menos
    41 m