Podcast appearances and mentions of Legacy code

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.

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

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.

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 comparable clarity—if the team respects those boundaries. He points to examples like Stripe or reading materials on Domain-Driven Design to show how cohesive object structures can help avoid big architectural hurdles.His closing thoughts revolve around long-term sustainability. Even if an engineer isn't planning to remain on a project indefinitely, they can leave a meaningful legacy by clarifying crucial parts of the code, championing simpler naming conventions, and encouraging more open dialogue among team members. The impact, Chris notes, goes beyond the immediate project: every person who touches that code later benefits from these improvements, often for years to come.Time-Stamped Highlights[00:00:00] Welcome and Well-Maintained Software:Robby opens by asking Chris about foundational traits of dependable, long-lasting codebases.[00:00:58] Defining “Well Maintained”:They explore how clear conventions and minimal bloat not only reduce confusion but also prolong the life of a system.[00:01:28] LLMs and Context Windows:Chris delves into why large codebases challenge AI-driven coding assistants—and how trim, well-modeled systems sidestep this pitfall.[00:02:00] Joining Shopify and Facing Legacy Systems:Chris recalls his early days at Shopify, realizing that older Rails apps demanded a more structured method of discovery.[00:03:08] Concept of “Developer Paradise”:He shares his perspective on how removing unneeded documentation and extraneous complexity makes daily development more enjoyable.[00:05:32] Framework for Tackling Old Code:Chris outlines his signature approach: booking numerous 1-on-1 meetings to gather honest feedback from stakeholders before touching the code.[00:07:15] Finding High-Leverage Problems:Robby and Chris discuss distilling this feedback into a shortlist of real bottlenecks that the team can tackle together.[00:15:00] From Problem Space to Solutions:They spotlight the value of framing a single unifying question—like “How do we reduce confusion?”—to keep everyone working toward the same outcome.[00:20:07] Balancing Personal Goals and Company Needs:Chris underlines how aligning individual ambitions with business objectives fosters commitment to sustained improvement.[00:32:00] Long-Term Value and Leadership:Closing out, Robby and Chris consider how short-tenure engineers can leave a lasting impact by helping a team focus on its biggest pain points.Resources & MentionsShopifyRuby on RailsChris's GitHubChris's LinkedInChris's Twitter/XThe One Thing by Gary KellerTitan: The Life of John D. Rockefeller, Sr. by Ron ChernowMartin Fowler on MicroservicesDomain-Driven Design

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 OrganizationThe Man Who Broke CapitalismHow to Make Things Faster

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 for permission to clean up their codebases.Episode Highlights[00:01:00] The characteristics of well-maintained software: modular design, good tests, and observability.[00:02:00] Open source vs. closed source software: Why communication matters more than you think.[00:04:50] Not all technical debt is worth paying down—how to decide when to refactor.[00:06:20] Developing engineering intuition: How experience shapes decision-making.[00:11:08] Lessons from refactoring a log processing system at Elastic.[00:17:09] Strategies for modernizing legacy systems without unnecessary rewrites.[00:19:52] Why maintainability is a business requirement, not an afterthought.[00:24:03] Should developers ask for permission to clean up code or just do it?[00:27:00] The impact of good commit messages and pull request documentation (GitHub PR Templates).[00:30:00] Are issue templates in open source a helpful guardrail or a barrier?[00:32:00] How to gain autonomy as a developer and advocate for technical improvements.[00:39:00] Noémi's advice: Only fix problems that are actually problems.Resources MentionedNoémi Ványi's WebsiteNoémi Ványi on GitHubElasticGitHub Pull Request TemplatesGitHubBook RecommendationLost in Thought: The Hidden Pleasures of an Intellectual Life by Zena Hitz

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 the challenges of communication in remote teams, the value of autonomy in software development, and how teams can make a case for technical debt reduction even when leadership isn't prioritizing it. If you've ever struggled with refactoring legacy systems or advocating for improvements, this conversation is packed with practical lessons.

Ivett Ördög speaks with host Sam Taggart about rewrite versus refactor -- a choice that many projects face as they grow. It's a topic that inspires a lot of dogmatic feelings. They discuss how companies and projects end up at this crossroads and consider some strategies to try to avoid it. Ivett challenges the myth that you should never rewrite but points to two key factors that need to be present for a successful large-scale rewrite or refactor. They end by talking about how to get management on board for such large-scale rewrite or refactor projects. Brought to you by IEEE Computer Society and IEEE Software magazine.

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 maintain RubyGems? Marty's role at Ruby Central.[00:14:00] Security in package management: How RubyGems handles vulnerabilities.[00:16:40] The role of external audits: Partnering with Trail of Bits for security improvements.[00:20:40] EU Cyber Resilience Act: How new regulations might affect open-source projects.[00:26:00] Funding open source: Why corporate sponsorships are becoming essential.[00:33:40] Advocating for technical debt work in teams: How to make a compelling case.[00:38:20] Processes in distributed teams: Balancing structure with flexibility.Key TakeawaysTechnical debt is often misunderstood. The real issue may not be shortcuts taken in the past, but the way software naturally drifts from its original purpose.Security in package management is a growing concern. Open-source ecosystems like RubyGems require continuous investment to remain secure.Open source needs sustainable funding. Relying on volunteers is not a long-term solution—companies need to contribute via corporate sponsorships.Advocating for code improvements requires strategy. Engineers should frame technical debt discussions around business impact, not just code quality.Resources MentionedMarty Haught on LinkedInMarty Haught on TwitterRuby CentralRubyGemsAuditing the Ruby Ecosystem's Central Package Repository – Trail of BitsEU Cyber Resilience Act OverviewWhat the EU's New Software Legislation Means for Developers (GitHub Blog)Ruby Central Open Source Program – Get InvolvedCorporate Sponsors ProgramGive and Take by Adam GrantConnect with MartyLinkedInTwitterBlueSkyThanks to Our Sponsor!Need a smoother way to share your team's inbox? Jelly's got you covered!

Show NotesMike 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!

Stride's Michael Carlson and Michael Wytock join this week's episode to share how Stride's groundbreaking 100x service is transforming legacy code modernization. They explore how Generative AI and automation are breaking down the barriers that have long made updating outdated systems slow, risky, and politically challenging.The duo shares how Stride 100x streamlines the modernization process by automatically tracing and understanding even the most complex legacy systems. The approach reduces what used to take weeks—or even months—to mere hours, enabling companies to modernize without disrupting their day-to-day operations. Plus, the two explore real-world legacy software challenges, from unknown system dependencies to hidden code risks, and explain how 100x eliminates these pain points through cutting-edge technology. They also explore how Stride 100x differs from popular tools like GitHub Copilot. If your organization is stuck in the old legacy systems, tune in now and discover how Stride 100x can help you modernize your systems. You can learn more about the service at https://www.stride.build/100x or chat with the team for a personalized demo. “Re-architecting and modernizing your applications as the business needs arise is not something that's going counter to what the business is trying to do. Actually, it will help the business move forward.” ~ Michael CarlsonIn This Episode:- Introducing Stride 100x: modernizing legacy applications- The birth of 100x from understanding client pain points- Identifying common legacy software struggles- Step 1 of 100x: code tracing in legacy systems- Speeding up the modernization process: real-world examples - Continuous monitoring and iteration with 100x- Stride 100x vs. popular AI coding tools- The future of legacy code modernization with Stride 100xAnd much more!Learn More About Stride 100x:https://www.stride.build/100xConnect with Debbie Madden:Website - https://www.stride.build/LinkedIn - https://www.linkedin.com/in/debbiemadden1/LinkedIn - https://www.linkedin.com/company/stride-consulting/

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 Takeaways:[00:01:00] What makes software well-maintained: documentation, accessibility, and automated tests.[00:03:10] Why documentation isn't just for new users—Lorna's experience with revisiting her own open source projects.[00:06:30] Diving into rst2pdf: Challenges in maintaining an abandoned project.[00:13:45] Balancing ownership and transitioning open source projects to new maintainers.[00:15:30] What is OpenAPI, and how does API governance impact usability?[00:26:10] The art of concise yet helpful documentation for different audiences.[00:33:00] Using examples in APIs to enhance clarity and reduce confusion.[00:40:00] Tools for improving writing, from prose linters to markdown syntax checkers.Resources Mentioned:Lorna Mitchell's Websiterst2pdf ProjectSimon Willison's Post on One-Person ProjectsHow to Take Smart NotesOpenAPI SpecificationVeil Prose LinterFollow Lorna:GitHubIndieWebThanks 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 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 teams to balance technical experimentation and maintainability.[00:14:03] Practical techniques for documenting architecture and decisions.[00:16:17] What is the Modularity Maturity Index (MMI), and how does it measure system health?[00:18:02] Common mistakes in managing technical debt and how to avoid them.[00:21:20] Why domain knowledge is essential for innovation and problem-solving.[00:33:03] Evolving legacy systems with domain-driven design and transformation.Key TakeawaysModularity matters: Simplified, modular systems with high cohesion and loose coupling reduce cognitive load and technical debt.Patterns as a shared language: Establishing a pattern language within your team creates consistency and eases onboarding.Cognitive science in software: Architecture aligned with how our brains process complexity results in more maintainable systems.Domain knowledge drives innovation: Teams should focus their creativity on solving domain-specific problems, not over-complicating the architecture.The value of architecture documentation: Keeping clear decision records helps teams navigate legacy code and onboard new developers.Resources MentionedCarola's LinkedInWPS WebsiteCarola's books:Sustainable Software ArchitectureDomain-Driven Transformation (English version coming soon)Modularity Maturity Index OverviewBooks Carola recommends:Reinventing Organizations by Frédéric LalouxTeam Topologies by Matthew Skelton and Manuel PaisBe sure to follow Carola on LinkedIn and X.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.

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 changes—provides the foundation for high-quality software.[00:03:05] Accessibility as a PriorityThe Microsoft acquisition drove GitHub's investment in accessibility, introducing SLAs, automated tools, and manual processes to track progress.[00:08:49] Primer: GitHub's Design SystemPrimer fosters consistency but introduces the challenge of making changes across a vast, interconnected system.[00:12:54] The Cost of Frontend ComplexityJoel shares how browser quirks, device diversity, and other variables make frontend maintenance far more expensive than backend systems.[00:28:05] Where to Start with AccessibilityJoel recommends focusing on key user workflows like signing up, making payments, and completing core tasks. He emphasizes the importance of tools like Axe and keyboard-driven tests.Notable Time-Stamps[00:01:12] What Makes Software Well-Maintained? Joel shares how changeability drives quality.[00:03:05] GitHub's Accessibility Journey: The role of SLAs, audits, and automation.[00:08:49] Primer and Design Systems: Balancing consistency with innovation.[00:12:54] The Hidden Costs of Frontend Complexity: Lessons learned at GitHub.[00:20:33] Balancing Creativity with Usability: Joel reflects on the intersection of design and functionality.[00:28:05] Accessibility Best Practices: Where teams should focus their initial efforts.ResourcesJoel Hawksley's WebsitePrimer Design SystemAxe Accessibility ToolsGitHub's ViewComponent FrameworkBook Recommendation:How Buildings Learn by Stewart BrandGuest's LinksJoel Hawksley on GitHubJoel Hawksley's WebsiteThanks 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.

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 of breaking up a monolithic GraphQL server and the challenges faced during the transition.[00:05:56] GraphQL vs. REST: How GraphQL aids developer productivity while maintaining backward compatibility.[00:10:53] Collaboration between data and application teams: Using tools like Kafka to bridge gaps and improve workflow.[00:17:00] Upgrading Ruby on Rails applications: Balancing autonomy with central guidance for seamless updates.[00:27:55] Fostering ownership on teams: The cultural practices that empower engineers to take initiative and drive results.[00:34:29] Prioritizing work effectively: How Austin's team uses quarterly planning and measurable "goalposts" to align efforts with impact.[00:40:00] Avoiding bike-shedding: Keeping meetings and reviews focused on meaningful progress.Key TakeawaysSimplicity Wins: Maintainable software is easier to adapt, remove, and iterate on when it's kept simple.Iterate and Refine: Use principles like YAGNI to avoid over-engineering and ensure systems are built to evolve.Collaboration Drives Success: Bridging communication between specialized teams can unlock untapped potential.Focus on Outcomes: Define clear goals and track measurable results to ensure projects align with business needs.Resources MentionedYAGNI (You Aren't Gonna Need It)GraphQL Federation OverviewDoximity Technology BlogThe Mom Test by Rob FitzpatrickAustin Story on LinkedInAustin Story's WebsiteStay ConnectedFollow Austin:LinkedInWebsiteThanks 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.

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] Communicating the impact of resource constraints.[00:19:27] Tracing single requests to understand complex systems.Industry Trends and AI's RoleFrom managed services to the impact of AI on coding languages, Dan reflects on how the industry continues to evolve.[00:35:05] Managed services as accelerators for maintainability.[00:41:25] The potential and limits of AI in software development.Key TakeawaysConsistency and documentation in codebases reduce cognitive overhead for developers.Understand how your software fits into the business to prioritize effectively.AI might reshape the industry, but it won't replace the need for thoughtful problem-solving.Opinionated frameworks like Ruby on Rails continue to offer exceptional developer ergonomics.Resources MentionedFusionAuth BlogDan's Personal BlogCIAM Weekly NewsletterDan's Book: Letters to a New DeveloperZen and the Art of Motorcycle MaintenanceThe Asimov story mentionedTry FusionAuthDownload FusionAuth: Get started with the self-hosted version today.Free Trial of FusionAuth: Experience the FusionAuth cloud for free!Connect with DanLinkedInBlueSkyThanks 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 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 Multiplayer's tools simplify the debugging process.[00:25:00] Design Branches and Team Collaboration: Enhancing communication through shared documentation.[00:31:39] Prioritizing Technical Debt: Identifying customer and developer pain points.Resources MentionedMultiplayerTom Johnson on LinkedInTom Johnson on TwitterBook Recommendation: Making Comics by Scott McCloudThanks 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.

Robby sits down with Justine Gehring, an AI Research Engineer at Moderne, to explore how AI tools are transforming code maintenance and scalability. They dive into the unique ways AI can support refactoring for massive and legacy codebases, from retrieval-augmented generation (RAG) to lossless semantic trees, and discuss how developers can benefit from AI-assisted planning and refactoring.Justine shares her background transitioning from academia to industry and reflects on the essential role of reproducibility in AI, why maintainable code is often overlooked in research, and the challenges of balancing innovation with real-world reliability in software projects.Topics DiscussedWhat Makes Software Maintainable: Justine's take on good documentation, reusable code, and ensuring new team members can quickly navigate a codebase. [00:00:42]Academia vs. Industry in Code Maintainability: Why reproducibility and code maintenance often diverge in research settings, and how industry standards address this gap. [00:01:14]From Academia to AI Engineering: Justine shares her journey and how her background in machine learning led to a career in AI-focused software maintenance. [00:04:48]Scaling Refactoring with OpenRewrite: An introduction to OpenRewrite, the open-source tool that facilitates large-scale code transformations, developed by Moderne. [00:12:15]Lossless Semantic Trees: The benefits of LSTs for detailed code analysis, retaining essential syntax and type information critical for reliable AI refactoring. [00:20:24]Retrieval-Augmented Generation (RAG): Justine explains RAG's significance in allowing AI models to provide context-specific responses without heavy re-training. [00:26:00]Trust and Validation in AI-Generated Code: The importance of robust test cases and human oversight when leveraging AI-generated code to avoid cascading errors. [00:31:36]AI as a Planning Tool for Refactoring Projects: Justine's insights on using AI as a collaborative coding assistant, offering developers suggestions for planning refactoring and maintenance tasks. [00:35:24]Real-World Example of Scaling Refactoring: Justine recounts a case study where Moderne used OpenRewrite to facilitate large-scale code migration involving multiple frameworks. [00:42:00]Advocating for AI Tools in Code Maintenance: Tips for developers interested in introducing AI tools and approaches within their teams or organizations. [00:42:31]Key TakeawaysAI Supports Reproducibility and Reliability: Ensuring reproducibility in AI-driven tools can enhance both credibility and usability for complex codebases.Prioritize Planning Before Refactoring: Understanding code dependencies and structure is key to successful refactoring; AI tools like OpenRewrite can automate targeted changes.Human Expertise Remains Essential: AI can be an effective coding assistant, but human oversight is necessary to ensure accuracy and quality.Experiment and Scale: Start with small, impactful AI-assisted refactoring recipes and scale up once the process is reliable, saving significant development hours over time.ResourcesModerneJustine Gehring's LinkedInOpenRewrite DocumentationGetting to Yes by Roger Fisher and William UryThanks 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.

As a product advocate at Nx, Katerina Skroumpelou combines her engineering skills with a knack for connecting with clients. In this episode, she shares how clear documentation, scalable architectures, and a collaborative culture can transform software development for the better.Key Takeaways[00:01:25] Katerina's Background: Robby and Katerina discuss her career journey, starting in engineering and recently moving into product advocacy.[00:02:29] Characteristics of Well-Maintained Software: Katerina highlights key aspects of maintainable software—readability, scalability, and reliability.[00:04:39] Product Advocacy at Nx: Katerina describes her unique role, bridging technical support and customer outreach to ensure clients make the most of Nx tools.[00:07:01] White Glove Approach: The “white glove” service approach allows Katerina to dive deep into clients' codebases, offering a hands-on approach to using Nx effectively.[00:09:52] Scalable Documentation Practices: Balancing clarity and detail, Katerina provides tips on structuring code comments and READMEs to be concise yet thorough.[00:12:09] Managing Technical Debt: Robby and Katerina discuss the importance of keeping code up-to-date and scalable, especially in large systems with high demands.[00:16:00] The Importance of Collaboration: Moving from solo work to team-based code reviews taught Katerina the value of a collaborative approach to maintainable code.[00:19:15] Nx's Monorepo Solution: How Nx provides cache and build tools to optimize mono-repo performance, boosting both speed and organization within projects.[00:22:12] Nx Cloud and CI: Katerina discusses Nx Cloud's role in enhancing CI workflows by allowing parallel tasks and cache sharing across teams.[00:24:07] When to Consider Monorepos: Katerina explains the benefits of monorepos for organizing codebases and improving scalability.[00:26:37] AI Tools in Development: Katerina shares her enthusiasm for new AI tools like StackBlitz's Bolt and their potential to streamline app development.[00:29:00] Finding Motivation at Work: Advice for developers who feel stuck or unmotivated in their current roles and ways to reconnect with the work they enjoy.Resources MentionedNx DevStackBlitz Bolt.newBooks:The Three-Body Problem by Cixin LiuCryptonomicon by Neal StephensonSlaughterhouse-Five by Kurt VonnegutKaterina's social profiles:LinkedInTwitterBlueskyThanks 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.

AI is being integrated and adopted across much of the IT world, but can it work magic in transforming old legacy code into shiny modern code? When it comes to this magic trick, it’s important to look behind the curtain. On today’s Day Two DevOps podcast we discuss the reality of AI in refactoring code... Read more »

AI is being integrated and adopted across much of the IT world, but can it work magic in transforming old legacy code into shiny modern code? When it comes to this magic trick, it’s important to look behind the curtain. On today’s Day Two DevOps podcast we discuss the reality of AI in refactoring code... Read more »

AI is being integrated and adopted across much of the IT world, but can it work magic in transforming old legacy code into shiny modern code? When it comes to this magic trick, it’s important to look behind the curtain. On today’s Day Two DevOps podcast we discuss the reality of AI in refactoring code... Read more »

Welcome to another engaging episode of the Maintainable Software Podcast! In this episode, Robby sits down with Moriel Schottlender, Principal Software Engineer at the Wikimedia Foundation, to explore the complex journey of modernizing MediaWiki, the software behind Wikipedia. Moriel shares her insights on what it takes to keep an enormous monolithic codebase maintainable while supporting an ever-growing and diverse set of global users. She highlights the importance of modularization, ownership, and the delicate balance between flexibility and stability in open-source software.Key Takeaways[00:00:51] Characteristics of Well-Maintained Software: Moriel discusses the three crucial characteristics of well-maintained software: ownership, modularization, and documentation.[00:01:09] Ownership and Rules for Contribution: Ownership goes beyond just fixing bugs—it involves understanding the architectural purpose and maintaining consistency even as teams change.[00:03:35] Product Vision's Role in Maintainability: Why a clear product vision is essential for maintaining software, even in the face of organic growth.[00:07:14] Balancing Experimentation and Long-Term Planning: Moriel shares insights into how Wikimedia balances rapid experimentation with careful, long-term architectural planning.[00:07:32] The Evolution of MediaWiki: MediaWiki's growth from a small project to the backbone of Wikipedia, now supporting over 900 wikis, and the challenges that come with scaling.[00:14:18] Modernizing a 23-Year-Old Monolith: Robby and Moriel dive into the challenges of modernizing MediaWiki's architecture, including the difficulties of updating a monolithic structure.[00:17:15]Wikitext vs. Markdown: Moriel explains why MediaWiki uses its own Wikitext language instead of Markdown and the unique challenges it presents.[00:22:25] Architectural Flexibility for the Future: The importance of having a flexible architecture that can adapt to the evolving needs of users and technologies.[00:26:04] Technical Debt and Modularization: How Wikimedia approaches technical debt in MediaWiki and prioritizes architectural interventions to improve modularity and maintainability.[00:39:00] Community Contributions to MediaWiki: Strategies for increasing developer contributions and how Wikimedia empowers volunteers while maintaining software quality.[00:41:59] Advice for Aspiring Open Source Contributors: Moriel shares encouraging words for anyone looking to contribute to open-source projects, emphasizing that everyone can make a meaningful impact.[00:35:44] The Role of Documentation: Moriel discusses Wikimedia's efforts to improve documentation and ensure it's useful for both developers and end-users, leveraging the strengths of wiki-based contributions.[00:30:29] Celebrating Small Wins: Moriel talks about how Wikimedia celebrates small victories to keep team morale high in the face of big challenges.Resources MentionedMoriel's WebsiteMoriel on MastodonMediaWiki DocumentationBook Recommendation:Year Zero by Rob ReidConnect with MorielMoriel on LinkedInInstagramTwitterGitHubMastodonThanks 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.

Welcome to another engaging episode of Maintainable! Robby sits down with Kate Holterhoff, Ph.D., a Senior Analyst at RedMonk and former front-end engineer, to explore the intricate world of software maintenance, documentation, and the future of developer roles. Kate brings her unique perspective from her time as a practitioner at a digital marketing agency, her academic background, and her current role in developer advocacy.Topics Explored[00:00:00] Introduction to Kate's Background: Robby and Kate discuss her journey from academia to front-end engineering and now to being a Senior Analyst at RedMonk. Kate shares how her experiences have shaped her perspective on software maintenance.[00:04:00] Well-Maintained Software: Kate dives into her definition of well-maintained software, emphasizing modularity, semantic readability, and the importance of considering future developers who will interact with the code.[00:11:30] The Challenges of Agency Work: Kate reflects on her time at a digital marketing agency, where she often worked on projects that had passed through many hands. She discusses the importance of balancing quick deliverables with maintainability.[00:20:45] The Role of Documentation: Kate shares insights on the value of documentation for distributed teams, highlighting her experience organizing documentation sessions ("documentation paloozas") to capture team knowledge and ensure maintainability.[00:30:00] RedMonk and Developer Advocacy: Kate explains her role at RedMonk and how the firm differs from traditional analyst firms like Gartner. She discusses RedMonk's focus on developers as key decision-makers in the tech landscape.[00:39:15] Front-End Developers as Kingmakers: Robby and Kate explore how front-end engineers are increasingly influencing the adoption of tools and technologies within organizations. Kate describes this trend as front-end developers becoming "kingmakers" in the industry.[00:49:50] AI and Developer Tools: Kate discusses the integration of AI into developer tools, the potential benefits, and challenges for junior developers. She emphasizes the importance of understanding how to read code in an AI-assisted world.Key Takeaways:Emphasize modularity and semantic readability to ensure code can be easily maintained by future developers.Documentation is crucial for maintainability, especially in distributed and contractor-heavy teams.Front-end developers are becoming key decision-makers, influencing tool and technology adoption.AI is increasingly integrated into developer workflows, making it essential for developers to focus on reading and understanding code.The definition of a 'developer' is evolving, with more abstracted tools and AI playing a larger role in development processes.Resources Mentioned:RedMonkKate Holterhoff on LinkedInKate Holterhoff on TwitterDarwin's The Origin of SpeciesEpisode Highlights:[00:00:00] Introduction to Kate's Background[00:04:00] Characteristics of Well-Maintained Software[00:20:45] The Importance of Documentation[00:30:00] What Does a Senior Analyst at RedMonk Do?[00:39:15] Front-End Developers as Kingmakers[00:49:50] The Role of AI in Developer ToolsThanks 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.

“Legacy code is a code without tests. If you have code, and it has lots of tests, it's relatively easy to change. But if you don't have the tests, you're really in serious trouble.” Do you dread working with legacy code? Michael Feathers, renowned software expert and author of the classic “Working Effectively with Legacy Code,” joins me to discuss the challenges and strategies for working with legacy code, a topic that remains highly relevant even after 20 years! Michael explains why he defines legacy code as “code without tests,” emphasizing the crucial role of automated tests for code maintainability, rather than simply defining it as an old inherited code. He also provides insights on the psychological challenges of working with legacy code and stresses the importance of approaching it with curiosity and a sense of adventure. The conversation also explores the evolving world of AI assistant in software development, drawing from Michael's forthcoming book, “AI-Assisted Programming”. He shares how AI can assist developers in various tasks, such as explaining code, identifying potential issues, generating tests, and exploring new possibilities. Listen to this episode to explore the intersection of legacy code, AI, and the future of software development!   Listen out for: Career Journey - [00:01:24] “Working Effectively with Legacy Code” Book - [00:02:05] Definition of Legacy Code - [00:04:55] The Importance of Automated Tests - [00:06:39] Understanding Legacy Code - [00:09:47] Mindset for Working with Legacy Code - [00:11:15] Rewrite vs Fixing Legacy Code - [00:13:50] Microservice for Legacy Code - [00:15:36] Approach to Dealing with Legacy Code - [00:17:33] Seams - [00:20:03] Strangler Fig - [00:21:42] Understanding Refactoring - [00:22:48] Testing Pyramid - [00:24:28] Code Nobody Wants to Touch - [00:26:10] AI for Understanding Legacy Code - [00:27:53] AI Churning More Legacy Code - [00:30:06] “AI Assisted Programming” Book - [00:32:47] Prompt Engineering - [00:34:16] Doing in Small Steps - [00:35:09] Best Use Case for AI - [00:37:29] Developer's Fear of AI - [00:39:16] SudoLang - [00:40:59] AI as Test Assistant - [00:43:42] Context Window - [00:45:19] Waywords - [00:47:14] Managing AI Sessions - [00:48:53] Using Different AI Tools - [00:50:30] 3 Tech Lead Wisdom - [00:52:28] _____ Michael Feathers's BioMichael Feathers is the Founder and Director of R7K Research & Conveyance, a company specializing in software and organization design. Over the past 20 years he has consulted with hundreds of organizations, supporting them with general software design issues, process change and code revitalization. A frequent presenter at national and international conferences, Michael is also the author of the book Working Effectively with Legacy Code. Follow Michael: Twitter – @mfeathers LinkedIn – linkedin.com/in/michaelfeathers Substack – substack.com/@michaelfeathers

Alan Ridlehoover: Building Robust Systems Through Behavior-Centric TestingIn this episode of Maintainable, Robby speaks with Alan Ridlehoover, Senior Engineering Manager at Cisco Meraki. Alan shares his perspective on building well-maintained software by focusing on behavior-centric testing, clear code ownership, and thoughtful technical decisions that stand the test of time.Alan discusses his experience working in both startup environments and large-scale engineering teams, including how he navigates the unique challenges of each. He provides practical advice on managing conditional logic in code, scaling with third-party dependencies, and ensuring that testing strategies remain effective as systems grow in complexity.Key Takeaways:The characteristics of well-maintained software: behavior-centric testing, solid code principles, and ownership boundaries.Balancing the needs of startups vs. large enterprises when it comes to software maintenance.Alan's approach to handling conditional logic with a technique called "rehydration" to simplify complex code.Why focusing on behavior, not implementation, is critical for scalable, maintainable tests.The importance of interfaces and facades for managing third-party dependencies and future scalability.How to approach technical debt as a conscious trade-off, not an inevitable burden.Best practices for addressing flaky tests, including managing non-determinism, order dependencies, and race conditions.How to set up effective monitoring and alerting systems to maintain a healthy software environment.The role of team structure and product ownership in delivering sustainable, high-quality software.Episode Highlights:[00:05:32] Introduction to the Guest's Background: Robby and Alan discuss Alan's work at Cisco Meraki and his approach to well-maintained software.[00:15:10] The Importance of Behavior-Centric Testing: Alan explains why focusing on behavior, not implementation, helps in both startups and large-scale environments.[00:24:30] Rehydration: A Strategy for Managing Conditional Logic in Code: Alan shares his method for simplifying code with many conditionals.[00:35:00] Navigating Technical Debt: Alan offers advice on how to strategically manage technical debt without slowing down business needs.[00:45:18] Monitoring and Alerting: Alan's tips on keeping systems healthy and avoiding customer-facing issues through smart monitoring setups.Resources Mentioned:Radical Candor by Kim ScottThe Code GardenerConnect with Alan Ridlehoover:LinkedInThe Code Gardener Blog 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 Mob Mentality Show episode, Chris Lucian and Austin Chadwick dive into the complexities of modern CI/CD (Continuous Integration / Continuous Delivery) pipeline code and IaC (Infrastructure as Code), exploring why these critical components of software delivery often exhibit the same problematic attributes as classic Legacy Code. Drawing inspiration from Michael Feathers' seminal book *Working Effectively with Legacy Code*, they analyze the paradox of cutting-edge DevOps practices turning into technical debt almost as soon as they're written. ### Episode Highlights: - **CI/CD Pipeline Code and Legacy Code Parallels**: Why does so much CI/CD and IaC code resemble legacy code? Despite being crucial for continuous delivery and automation, CI/CD pipelines can become fragile, difficult to change, and filled with technical debt if not handled carefully. Austin and Chris discuss why this phenomenon is so common and what makes the codebases for CI/CD pipelines especially prone to these issues.    - **“Edit and Pray” vs. TDD Confidence**: Do your CI/CD changes feel like a roll of the dice? Chris and Austin compare how the lack of test-driven development (TDD) practices in CI/CD code leads to “edit and pray” scenarios. They discuss the confidence that TDD brings to traditional application development and how applying similar principles could reduce fragility in CI/CD code. - **The Pitfalls of YAML in IaC**: Is the problem inherent to YAML? The hosts explore whether the complexity of YAML syntax and configurations is the root cause of the brittleness often found in IaC. They provide real-world examples of IaC configurations that suffer from high cyclomatic complexity—making them feel more like full-blown applications rather than simple configuration files. - **Fear of Change in CI/CD and IaC**: Why are developers often afraid to modify CI/CD pipeline code or IaC? Chris and Austin highlight the psychological aspects of fragile infrastructure—where fear of unintended consequences and lack of fast feedback loops result in slower iterations and more bugs. They explore why these codebases are often re-written from scratch instead of extended and safely enhanced. - **Reducing Fragility through Experiments**: The episode features a recent experiment where CI/CD pipeline code was developed in Python using TDD and separation of concerns. This case study reveals the pros and cons of less YAML and a shift towards more code-based "configurations." Could this approach be a solution to reducing brittleness in IaC and pipelines? - **A World Without Brittle Pipelines?**: Imagine a world without fragile pipelines and brittle configuration files. Chris and Austin discuss strategies to move towards more resilient infrastructure and how teams can focus on improving feedback loops, reducing complexity, and enabling safer, faster CI/CD iterations. Join Chris and Austin as they explore these and other crucial topics that are impacting DevOps teams around the world. Whether you're struggling with high bug rates in your pipelines, slow feedback loops, or simply want to better understand how to manage the complexity of modern infrastructure, this episode is for you! Video and Show Notes: https://youtu.be/3Cs-j055b9g 

In this episode of Maintainable, Robby speaks with April Wensel, Founder and Owner of Compassionate Coding. April shares her journey in the software industry and how she came to embrace compassion as a core value in coding and team dynamics. She explains why empathy is critical when working with legacy code, mentoring junior developers, and addressing technical debt.Episode Highlights[00:05:32] Introduction to Compassionate Coding: April discusses the mission behind Compassionate Coding and why human-centered development is essential.[00:13:36] Compassion and Technical Debt: How fostering a compassionate mindset helps teams navigate the challenges of maintaining legacy code and tackling technical debt.[00:20:10] Empathy in Code Reviews: April talks about the role of compassion in creating healthy, constructive code review cultures.[00:26:30] Onboarding with Compassion: The importance of pairing and empathy in onboarding new engineers, whether junior or senior.[00:31:55] The Refactor vs. Rewrite Debate: April explains why she usually sides with refactoring over rewriting code, and how compassion can inform that decision.[00:41:20] The Role of Leadership in Code Quality: How leaders can set the tone for compassionate coding by prioritizing better documentation and creating a supportive team environment.[00:44:56] Community Service and Building Empathy: April shares how volunteering outside of tech has helped her develop empathy that translates into better teamwork and communication in the workplace.Key Takeaways:Compassion in coding isn't just about clean code; it's about how we treat ourselves and others in the process of writing and maintaining software.Legacy code doesn't have to be a source of frustration; by embracing empathy and self-compassion, teams can tackle it with a positive mindset.Pairing and mentorship are powerful tools in onboarding, helping to bring new team members into a supportive, inclusive environment.Effective communication with stakeholders about technical debt requires empathy and understanding of their priorities.Compassionate coding also extends beyond the development team, influencing interactions with non-engineers, users, and the broader community.Resources:Compassionate CodingApril's Twitter12 Steps to a Compassionate Life by Karen ArmstrongFollow April Wensel:LinkedInTwitterWebsiteThanks 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 the Maintainable Software Podcast, Robby sits down with Saron Yitbarek, founder and CEO of DiscoLink, to explore the challenges of maintaining early-stage software while balancing multiple streams of income. Saron shares her journey from being a solo developer to hiring her first teammate and the lessons learned along the way about code maintainability and business logic.Episode Highlights[00:05:32] Introduction to Saron's Background: Robby and Saron discuss her startup, DiscoLink, and the initial development of its MVP.[00:10:50] The Importance of Context in Code: Saron emphasizes why understanding the business decisions behind code is crucial for maintainability.[00:15:10] Onboarding a New Developer: Saron shares her experience hiring her first developer and how it changed her approach to software maintenance.[00:20:32] Multiple Streams of Income: Saron explains her motivation behind building DiscoLink to help professionals manage different revenue streams.[00:25:40] Transparency Around Money: A candid conversation about developers' fears around charging for their work and how to overcome them.[00:30:45] Ethics and Side Projects: Robby and Saron discuss ethical considerations when working on side projects while employed full-time.[00:35:12] How Podcasting Shaped Saron's Career: Saron talks about how being a podcast host impacted her career growth and networking.Key TakeawaysMaintainability Beyond Code: Saron highlights the importance of documenting not just the code but also the business rationale behind decisions.Onboarding Challenges: Bringing a new developer into a solo-built project requires strong communication, context sharing, and flexible documentation practices.The Power of Multiple Income Streams: Saron's vision with DiscoLink focuses on helping tech professionals build financial security through various revenue channels.Confronting Money Anxiety: Many developers struggle with charging for their work, but transparency and community conversations help break down those barriers.Ethical Side Projects: It's important to consider the ethical implications of using work-learned skills for personal projects.ResourcesSaron Yitbarek on LinkedInSaron Yitbarek on TwitterDiscoLink WebsiteBook Recommendation: Formerly Known as Food by Kristin LawlessLinks:My newsletter: https://themultihyphenate.ck.page/newsletterThanks 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.

Welcome to another episode of Swift Academy! This time, we're joined by Bogdan Poplauschi, an expert in iOS development, to tackle one of the most challenging aspects of software engineering—working effectively with legacy code. Together, we delve into the complexities of managing and improving older codebases, while maintaining their functionality and integrity.

YK Sugi, Senior AI Developer Advocate at Sourcegraph and founder of CS Dojo, shares his journey from coding with MATLAB to working at Google and founding his YouTube channel, and how ChatGPT inspired his shift towards AI-driven applications. Along with our hosts, he discusses AI's impact on coding, particularly in large codebases, and the role of tools like Sourcegraph's Cody and GitHub Copilot in improving developer workflows. They also explore how AI is evolving in code completion, legacy code, and its broader potential in development. Chapters Introduction and Guest Introduction 00:00 YK's Coding Journey 02:01 AI's Impact on YK's Career 07:31 AI in Large Codebases 11:01 Choosing AI Models for Coding 17:01 AI for Code Completion and Development Efficiency 21:01 The Future of AI in Software Development 26:31 AI and Human Creativity 32:01 Closing Remarks and Where to Find YK 36:01 Follow YK on Social Media Twitter: https://x.com/ykdojo Linkedin: https://www.linkedin.com/in/ykdojo/ Github: https://github.com/ykdojo

Ruben Casas discusses software migrations at scale, understanding different migration patterns, making critical decisions on whether a full rewrite is necessary, and more. This episode covers all the essentials you need to navigate your next big software transformation. Links https://www.linkedin.com/in/ruben-casas-17100383 github.com/infoxicator https://www.infoxicator.com/ https://x.com/Infoxicador https://www.youtube.com/c/RubenCasas We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr)

IntroductionIn this episode of Maintainable, Robby speaks with Lutz Hühnken, Head of Engineering Excellence at Upvest, about the transformative power of event-driven architecture in software development. Lutz brings his extensive experience to the table, discussing how breaking down complex systems into manageable modules and leveraging event-driven design can lead to more resilient and maintainable software.Topics Discussed[00:05:32] Introduction to Well-Maintained Software: Lutz shares his thoughts on the key characteristics of maintainable software, emphasizing modularity and simplicity.[00:10:24] Challenges with "Magic" in Code: The pitfalls of relying too much on frameworks and ORMs, including examples from Lutz's experience with Hibernate.[00:11:16] Understanding Event-Driven Architecture: Lutz explains the fundamentals of event-driven architecture and its advantages over traditional command-driven approaches.[00:13:50] The Role of Promises in Event-Driven Systems: How clear design-time responsibilities ensure reliability in event-driven communication.[00:15:43] Choreography vs. Orchestration: The debate between these two approaches to managing workflows and why Lutz favors choreography for most systems.[00:17:57] Onboarding Developers in Event-Driven Systems: Tips for effectively integrating new team members into an event-driven architecture.[00:26:52] The Role of Engineering Excellence at Upvest: Lutz discusses his new role and the importance of systems thinking in guiding architectural decisions.[00:34:55] Managing Technical Debt: Lutz offers insights into balancing feature development with addressing technical debt, emphasizing the importance of a healthy investment distribution.Key TakeawaysBreaking down large systems into smaller modules with clear boundaries can significantly enhance maintainability.Event-driven architecture offers a powerful way to decouple system components, making them more resilient and scalable.Developers should be cautious of "magic" in code, such as heavy reliance on ORMs, which can obscure underlying complexities and hinder maintainability.Choreography often provides a more scalable and maintainable approach than orchestration in managing complex workflows.Technical debt should be managed proactively, with regular investments in refactoring and productivity enhancements to maintain long-term software health.Resources MentionedLutz Hühnken's BlogEvent-Driven Architecture by Martin FowlerThe Open Society and Its Enemies by Karl PopperConnect with Lutz HühnkenLinkedInTwitterThanks 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.

Summary In this episode, Jimmy Fosdick joins Dave for a conversation about his journey from traditional project management to agile. They discuss the challenges of applying traditional project management to software development, the importance of understanding the context and problem domain when choosing project management approaches, and the misuse of the term 'agile' in the consulting industry. They also touch on the legacy of Frederick Taylor and the need for a people-centered approach in project management. The conversation explores the challenges of traditional project management and the need for a more empirical and agile approach. They discuss the problems with big upfront planning, the importance of shorter cycle times, and the fear of failure. The conversation also touches on the need for more humane workspaces and the changing nature of work. The principal themes include the limitations of traditional project management, the benefits of an empirical approach, and the evolving workforce and work environment. Takeaways • Traditional project management is effective for problems that can be solved on paper upfront, but may not work well for software development. • Agile approaches, such as Scrum, are better suited for software development and other complex, empirical problems. • The term 'agile' has become an overloaded and misused brand in the consulting industry. • Hybrid approaches that combine traditional project management and agile practices can be problematic and may not fully embrace the values and principles of agile. • A people-centered approach is essential in project management, and the focus should be on collaboration, respect, and solving the right problems. Traditional project management relies on upfront planning, which can lead to longer cycle times and higher failure rates. • An empirical approach, such as Agile, allows for shorter cycle times and the ability to adapt and change as needed. • The fear of failure often hinders organizations from embracing more agile and iterative approaches. • There is a growing emphasis on creating more humane workspaces and allowing for more flexibility and creativity in the workplace. • The nature of work is changing, and organizations need to adapt to the expectations and needs of the new generation of workers. Titles • The Misuse of the Term 'Agile' in the Consulting Industry • From Traditional Project Management to Agile: Jimmy Fosik's Journey The Changing Nature of Work • Overcoming the Fear of Failure Chapters 02:20 Introduction and Background 05:52 The Challenges of Traditional Project Management in Software Development 08:33 Differentiating Scrum from Traditional Project Management 12:13 The Misuse of the Term 'Agile' 14:38 The Problem with Hybrid Approaches 22:17 Legacy Code in Our Heads: Shifting the Project Management Paradigm 26:21 The Benefits of an Empirical Approach 28:46 Overcoming the Fear of Failure 33:18 Creating More Humane Workspaces 39:03 The Changing Nature of Work Contacting Jimi - Web: https://fearlessagility.com/ - X: https://x.com/FearlessAgility - Facebook: https://www.facebook.com/FearlessAgility/ - Instagram: https://www.instagram.com/realFearlessAgility/ - Courses on the Scrum Alliance site: https://tinyurl.com/yjc2rtmf Links from Dave's Intro - The Art of War for Collaboration Course http://modusinstitute.com/course/art-of-war-collaboration - Guided Personal Kanban (September 2024) http://modusinstitute.com/course/guided-pk-sep-usa The Agile Network* https://go.theagilenetwork.com/l/web-dprior Use the discount codes below to get either 20% or 2 months of free access 2 Free Months - DRUNKENPM10CM 20% off Annual - DRUNKENPM10C20 Contacting Dave Linktree: https://linktr.ee/mrsungo

In this episode of the Maintainable Software Podcast, Robby sits down with Cassidy Williams, Developer Advocate at GitHub, to explore the dynamic nature of a tech career, the delicate balance between clever code and maintainability, and the evolving trends in software development.Cassidy begins by discussing what makes software truly maintainable—starting with the ease of onboarding for new developers. She emphasizes the importance of clear documentation and warns against the pitfalls of writing overly clever code that might be difficult to maintain in the future.They then delve into the challenges of joining an existing codebase and managing technical debt. Cassidy shares her experiences, noting how codebases often start pristine but become more cumbersome as projects evolve and pivot.The Importance of Onboarding: Cassidy explains how fast someone can jump in and start working on code as a key indicator of well-maintained software.[00:10:21] Balancing Cleverness and Maintainability: Cassidy elaborates on why writing clever code can be a double-edged sword when it comes to long-term maintainability.[00:16:00] Navigating Career Pivots: Cassidy reflects on her own career journey, likening it to a "career jungle gym" where paths are non-linear and require thoughtful decision-making.[00:18:36] Working at Netlify: Cassidy shares her experience with upgrading a router within an existing codebase, highlighting the importance of collaboration and bringing in external expertise.[00:24:00] Local-First Software: Robby and Cassidy explore the trend of local-first software, emphasizing the benefits of data ownership and the ability to work offline.[00:26:30] Developer Wishlists: Cassidy suggests creating personal and communal wishlists for addressing technical debt, fostering a collaborative approach to maintaining software.[00:31:50] Jumbile - Cassidy's Side Project: Cassidy introduces her word game, Jumbile, detailing its development process and the unique challenges she faced.Cassidy also discusses her love for Brandon Sanderson's books, specifically the Mistborn trilogy, and the importance of owning your data in today's digital landscape.Key Takeaways:Maintainable software allows new developers to quickly contribute, thanks to clear documentation and readable code.Clever code can be a joy to write but may lead to maintenance challenges down the line.A career in tech often resembles a jungle gym, requiring flexibility and thoughtful navigation.Involving open-source maintainers in large codebase changes can provide invaluable insights and streamline the process.Local-first software is gaining traction, offering benefits in data ownership and offline functionality.Resources Mentioned:Cassidy's WebsiteCassidy on LinkedInCassidy on TwitterJumbile - Word GameReact RouterMistborn Trilogy by Brandon SandersonThanks 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! 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.

Topics Discussed:The importance of test coverage and readable code in maintaining software over time.How Ruby's syntax contributes to creating maintainable and human-readable code.Challenges and strategies for integrating external APIs, especially AI-driven ones like OpenAI.Obie's approach to creating robust systems using AI, including the use of guardrails and evals.An overview of Olympia, a platform leveraging AI to manage complex workflows and account interactions.The concept of "multitude of workers" where AI components handle discrete tasks in software.Obie's innovative methods for modifying business logic through natural language instructions.The evolving role of AI in software development, including self-healing data and error handling.A sneak peek into Obie's upcoming book, "Patterns of Application Development Using AI"The future of AI in software development, particularly within the Ruby on Rails community.Obie's thoughts on how AI will reshape our approach to legacy code and technical debt.Key Takeaways:AI can enhance software robustness by handling errors gracefully and dynamically adjusting to changes.Ruby's syntax and culture offer unique advantages for integrating AI into software development.The future of AI in software is not just about replacing code but evolving how we think about programming.Obie's approach to AI is about empowering developers to focus on higher-level tasks by automating routine processes.AI-driven development opens new opportunities for innovation, especially in the Ruby on Rails community.Resources Mentioned:OlympiaObie's LinkedInObie's TwitterObie's Medium BlogPatterns of Application Development Using AIThanks 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! 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.

Ryosuke shares his insights on:Ownership in Software Maintenance: The role of single-threaded ownership and dedicated teams in maintaining software and shared libraries.Technical Debt: How his definition of technical debt has evolved over the years and strategies to manage it effectively.Monitoring and Alarming: The importance of comprehensive monitoring and alarming systems in handling legacy software and ensuring reliability.Change Management: Best practices for change management, including preparing for worst-case scenarios and automating processes to reduce risks.Phased Rollouts and Feature Flags: Implementing phased rollouts and using feature flags to manage changes safely and gradually.Cell-Based Architecture: How cell-based architecture enhances scalability and reliability, and the challenges of maintaining multi-cell systems.Operational Excellence: Continuous deployment, regular dashboard reviews, and technologies used in orchestration to achieve operational excellence.Ryosuke also discusses his current role and responsibilities as a software engineer and his consulting work with OpsVL, where he helps organizations raise their operational standards.Resources MentionedRyosuke Iwanaga on LinkedInOpsBR Software Technology Inc.Cell-Based ArchitectureTune in to this insightful episode to learn more about maintaining healthy and scalable software systems.About the Guest:Ryosuke Iwanaga is the President of OpsBR Software Technology Inc. He has extensive experience in software engineering, including roles in sales engineering, support engineering, and data center operations. Ryosuke is passionate about operational excellence and helping organizations improve their software systems.Follow Ryosuke on Social Media:LinkedIn 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 special episode of Book Overflow, Michael Feathers joins Carter Morgan and Nathan Toups to reflect on his book "Working Effectively with Legacy Code." Join them as they discuss the pros and cons of TDD, the dangers of AI hallucination, and why Michael became a software engineer!

In this episode of Book Overflow, Carter Morgan and Nathan Toups discuss the second half of "Working Effectively with Legacy Code" by Michael Feathers. Join them as they discuss how to keep up a good attitude while working on legacy code, how to get started when you're intimidated, and some of the legacy and greenfield projects they've worked on in their careers! ------------ Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://bookoverflow.io https://x.com/bookoverflowpod

Everything we write becomes legacy code once it's written. That means technical debt in the future, so how can we do a better job today to help future us tomorrow?Become a Patreon member and help this Podcast survivehttps://www.patreon.com/compileswiftPlease leave a review and show your supporthttps://lovethepodcast.com/compileswiftYou can also show your support by buying me a coffeehttps://peterwitham.com/bmcFollow me on Mastodonhttps://iosdev.space/@Compileswift Thanks to our monthly supporters Arclite ★ Support this podcast on Patreon ★

In this episode of the Maintainable Software Podcast, Robby Russell sits down with James Socol, a Staff Engineer at Fastly, to discuss the art of maintaining legacy code and the nuances of technical debt versus technical depreciation.Key Topics Discussed:Characteristics of Well-Maintained Code: James shares his insights on what defines well-maintained code, emphasizing the importance of continuous maintenance, testing, and encapsulation.Technical Debt vs. Technical Depreciation: James introduces the concept of technical depreciation, distinguishing it from technical debt and explaining how time affects software maintenance.Balancing Old and New Patterns: The discussion explores the challenges of integrating modern standards into legacy systems and finding a healthy balance.20% Time for Maintenance: James advocates for dedicating a portion of engineering capacity to maintenance tasks, drawing parallels to Google's 20% time concept.Onboarding Strategies: James offers valuable advice for new hires, emphasizing observation, gradual involvement, and building social capital within the team.Continuous Delivery and Big Changes: Insights into managing significant changes in a continuous delivery environment, with practical strategies for maintaining stability.Resources Mentioned:Riot Engineering Blog: A Taxonomy of Tech DebtSilicon Valley Product GroupLaura Hogan's Donut TheoryBooks:Getting to Yes by Roger Fisher & William UryTurn the Ship Around by L. David MarquetThanks 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 soon, 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! 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.

Carter Morgan and Nathan Toups read and discuss the first half of "Working Effectively with Legacy Code" by Michael Feathers. Join them as they reflect on dependency inversion, the importance of interfaces, and continue their never-ending debate on the pros and cons of Test-Driven Development! (The audio gets a little de-synced in the last three minutes. Carter isn't talking over Nathan on purpose!) Chapter markers: 00:00 Intro  04:51 Thoughts on the book 10:54 Defining Legacy Code 21:53 Quick Break: Pull Requests 22:38 How to change software 44:30 Quick Break: CI/CD 45:15 Testing Legacy Code 1:15:10 Quick Break: Linting 1:16:01 Closing Thoughts 

Stephanie has a newfound interest in urban foraging for serviceberries in Chicago. Joël discusses how he uses AI tools like ChatGPT to generate creative Dungeons & Dragons character concepts and backstories, which sparks a broader conversation with Stephanie about AI's role in enhancing the creative process. Together, the hosts delve into professional growth and experience, specifically how to leverage everyday work to foster growth as a software developer. They discuss the importance of self-reflection, note-taking, and synthesizing information to enhance learning and professional development. Stephanie shares her strategies for capturing weekly learnings, while Joël talks about his experiences using tools like Obsidian's mind maps to process and synthesize new information. This leads to a broader conversation on the value of active learning and how structured reflection can turn routine work experiences into meaningful professional growth. Obsidian (https://obsidian.md/) Zettelkasten (https://en.wikipedia.org/wiki/Zettelkasten) Mindmaps in Mermaid.js (https://mermaid.js.org/syntax/mindmap.html) Module Docs episode (https://bikeshed.thoughtbot.com/417) Writing Quality Method docs blog post (https://thoughtbot.com/blog/writing-quality-method-docs) Notetaking for Developers episode (https://bikeshed.thoughtbot.com/357) Learning by Helping blog post (https://thoughtbot.com/blog/learning-by-helping) Transcript:  JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, as of today, while we record this, it's early June, and I have started foraging a little bit for what's called serviceberries, which is a type of tree/shrub that is native to North America. And I feel like it's just one of those, like, things that more people should know about because it makes these little, tiny, you know, delicious fruit that you can just pick off of the tree and have a little snack. And what's really cool about this tree is that, like I said, it's native, at least to where I'm from, and it's a pretty common, like, landscaping tree. So, it has, like, really pretty white flowers in the spring and really beautiful, like, orange kind of foliage in the fall. So, they're everywhere, like, you can, at least where I'm at in Chicago, I see them a lot just out on the sidewalks. And whenever I'm taking a walk, I can just, yeah, like, grab a little fruit and have a little snack on them. It's such a delight. They are a really cool tree. They're great for birds. Birds love to eat the berries, too. And yeah, a lot of people ask my partner, who's an arborist, like, if they're kind of thinking about doing something new with the landscaping at their house, they're like, "Oh, like, what are some things that I should plant?" And serviceberry is his recommendation. And now I'm sharing it with all of our Bike Shed listeners. If you've ever wondered about [laughs] a cool and environmentally beneficial tree [laughs] to add to your front yard, highly recommend, yeah, looking out for them, looking up what they look like, and maybe you also can enjoy some June foraging. JOËL: That's interesting because it sounds like you're foraging in an urban environment, which is typically not what I associate with the idea of foraging. STEPHANIE: Yeah, that's a great point because I live in a city. I don't know, I take what I can get [laughs]. And I forget that you can actually forage for real out in, you know, nature and where there's not raccoons and garbage [laughs]. But yeah, I think I should have prefaced by kind of sharing that this is a way if you do live in a city, to practice some urban foraging, but I'm sure that these trees are also out in the world, but yeah, have proved useful in an urban environment as well. JOËL: It's really fun that you don't have to, like, go out into the countryside to do this activity. It's a thing you can do in the environment that you live in. STEPHANIE: Yeah, that was one of the really cool things that I got into the past couple of years is seeing, even though I live in a city, there's little pieces of nature around me that I can engage with and picking fruit off of people's [inaudible 03:18] [laughs], like, not people's, but, like, parkway trees. Yeah, the serviceberry is also a pretty popular one here that's planted in the Chicago parks. So, yeah, it's just been like, I don't know, a little added delight to my days [laughs], especially, you know, just when you're least expecting it and you stumble upon it. It's very fun. JOËL: That is really fun. It's great to have a, I guess, a snack available wherever you go. STEPHANIE: Anyway, Joël, what is new in your world? JOËL: I've been intersecting two, I guess, hobbies of mine: D&D and AI. I've been playing a lot of one-shot games with friends, and that means that I need to constantly come up with new characters. And I've been exploring what AI can do to help me develop more interesting or compelling character concepts and backstories. And I've been pretty satisfied with the result. STEPHANIE: Cool. Yeah. I mean, if you're playing a lot and having to generate a lot of new ideas, it can be hard if you're, you know, just feeling a little empty [laughs] in terms of, you know, coming up with a whole character. And that reminds me of a conversation that you and I had in person, like, last month as we were talking about just how you've been, you know, experimenting with AI because you had used it to generate images for your RailsConf talk. And I think I connected it to the idea of, like, randomness [laughs] and how just injecting some of that can help spark some more, I think, creativity, or just help you think of things in a new way, especially if you're just, like, having a hard time coming up with stuff on your own. And even if you don't, like, take exactly what's kind of provided to you in a generative AI, it at least, I don't know, kind of presents you with something that you didn't see before, or yeah, it's just something to react to. JOËL: Yeah, it's a great tool for getting unstuck from that kind of writer's block or that, like, blank page feeling. And oftentimes, it'll give you a thing, and you're like, that's not really exactly what I wanted. But it sparks another idea, which is what I actually want. Or sometimes you can be like, "Hey, here's an idea I have. I'm not sure what direction to take it in. Give me a few options." And then, you see that, and you're like, "Oh, that's actually pretty interesting." One thing that I think is interesting is once I've come up with a little bit of the character concept, or maybe even, like, a backstory element...so, I'm using ChatGPT, and it has that concept of memory. And so, throughout the conversation, it keeps bringing it back. So, if I tell it, "Look, this is an element that's going to be core to the character," and then later on, I'm like, "Okay, help me brainstorm some potential character flaws for this character," it'll actually find things that connect back to my, like, core concept, or maybe an element of the backstory. And it'll give me like, you know, 5 or 10 different ideas, and some of them can be actually really good. So, I've really enjoyed doing that. It's not so much to just generate me a character so much as it is like a conversation back and forth of like, "Okay, help me come up with a vibe for it. Okay, now that I have a vibe or a backstory element or, like, a concept, help me workshop this thing. And what about that?" And if I want to say, "It's going to be this character class, what are maybe some ways I could develop it that are unusual?" and just sort of step by step kind of choose your own adventure. And it kind of walking me through the process has been really fun. STEPHANIE: Nice. Yeah, the way you're talking about it makes a lot of sense to me how asking it to help you, not necessarily do all of it, like, you know, kind of just spit out something that you're like, okay, like, that's what I'm going to use, approaching it as a tool, and yeah, that's really fun. Have you had good experiences then playing with those characters [chuckles]? JOËL: I have. I think it's also really great for sort of padding out some of the content. So, I had a character I played who was a washed-up politician. And at one point, I knew that I was going to have to make a campaign speech. And I asked ChatGPT, "Can you help me, like...here are the themes I want to hit. Give me a, like, classic, very politician-sounding speech that sounds inspiring but also says nothing at the same time." And it did a really good job of that. And you can tell it, "Oh, that's too long. That's too short. I want three sentences. I want five sentences." And that was great. So, I saved that, brought it to the table, and read out my campaign speech, and it was a hit. STEPHANIE: Amazing. That's really fun. I like that because, yeah, I don't think...I am so poor at just improvising things like that, even though, like, I want to really embody the character. So, that's cool that you found a way to help you be able to do that because that just feels like kind of what playing D&D can be about. JOËL: I've never DM'd, but I could imagine a situation where, because the DMs have to improv so much, and you know what the players do, I could imagine having a tool like that available behind the DM screen being really helpful. So, all of a sudden, someone's just like, "Oh, I went to a place," and, like, all of a sudden, you have to, like, sort of generate a village and, like, ten characters on the spot for people that you didn't expect, or an organization or something like that. I could imagine having a tool like that, especially if it's already primed with elements from your world that you've created, being something really helpful. That being said, I've never DM'd myself, so I have no idea what it actually is like to be on the other side of that screen. STEPHANIE: Cool. I mean, if you ever do try that or have a DM experience and you're like, hmm, I wonder kind of how I might be able to help me here, I bet that would be a very cool experience to share on the show. JOËL: I definitely have to report back here. Something that I've been thinking about a lot recently is the difference between sort of professional growth and experience, so the time that you put into doing work. Particularly maybe because, you know, we spend part of our week doing client work, and then we have part of the week that's dedicated to maybe more directly professional growth: our investment day. How do we grow from that, like, four days a week where we're doing client work? Because not all experience is created equal. Just because I put in the hours doesn't mean that I'm going to grow. And maybe I'm going to feel like I'm in a rut. So, how do I take those four days a week that I'm doing code and transform that into some sort of growth or expansion of my knowledge as a developer? Do you have any sort of tactics that you like to use or ways you try to be a little bit more mindful of that? STEPHANIE: Yeah, this is a fun question for me, and kind of reminds me of something we've talked a little bit about before. I can't remember if it was, like, on air or just separately, but, you know, we talk a lot about, like, different learning strategies on the show, I think, because that's just something you and I are very into. And we often, like, lean on, you know, our investment day, so our Fridays that we get to not do client work and kind of dedicate to professional development. But you and I also try to remember that, like, most people don't have that. And most people kind of are needing to maybe find ways to just grow from the day-to-day work that they do, and that is totally possible, I think. And some of the strategies that I have are, I guess, like, it is really...it can be really challenging to, like, you know, be like, okay, I spent 40 hours doing this, and like, what did I learn [chuckles]? Feeling like you have to have something to show for it or something to point to. And one thing that I've been really liking is these automated check-ins we have at the end of the week. And, you know, I suspect that this is not that uncommon for just, like, a workplace to be like, "Hey, like, how did your week go? Like, what are some ways that it was successful? Like, what are your challenges? Like, where do you need support or help?" And I think I've now started using that as both, like, space for giving an update on just, like, business-y things. Like, "Here's the status of this project," or, like, "Here's, you know, a roadblock that we faced that took some extra time," or whatever. Then also being like, oh, this is a great time to make this space for myself, especially because...I don't know about you, but whenever I have, like, performance review time and I have to write, like, a self-review, I'm just like, did I do anything in the last six months [laughs], or how have I grown in the last six months? It feels like such a big question, kind of like you were talking about that blank page syndrome a little bit. But if I have kind of just put in the 10 minutes during my Friday to be like, is there something that was kind of just for me that I can say in my check-in? I can go back and, yeah, just kind of start to see just, like, you know, pick out or just pay attention to how, like, my 40 hours is kind of serving me in growing in the ways that I want to and not just to deliver code [laughs]. JOËL: What you're describing there, that sort of weekly check-in and taking notes, reminds me of the practice of journaling. Is that something that you've ever tried to do in your, like, regular life? STEPHANIE: Oh yeah, very much so. But I'm not nearly as, like, routine about it in my personal life. But I suspect that the routine is helpful in more of a, like, workplace setting, at least for me, because I do have, like, more clear pathways of growth that I'm interested in or just, like, something that, I don't know, not that it's, like, expected of everyone, but if that is part of your goals or, like, part of your company's culture, I feel like I benefit from that structure. And yeah, I mean, I guess maybe that's kind of my way of integrating something that I already do in my personal life to an environment where, like I said, maybe there is, like, that is just part of the work and part of your career progression. JOËL: I'm curious about the frequency. You mentioned that you sort of do this once a week, sort of a check-in at the end of the week. Do you find that once a week is about the right frequency versus maybe something like daily? I know a lot of these sort of more modern note-taking systems, Roam Research, or Obsidian, or whatever, have this concept of, like, a daily note that's supposed to encourage something that's kind of like journaling. Have you ever tried something more on a daily basis, or do you feel like a week is about...or once a week is about the right cadence for you? STEPHANIE: Listen, I have, like, complicated feelings about this because I think the daily note is so aspirational for me [laughs] and just not how I work. And I have finally begrudgingly come to accept this no matter how much, like, I don't know, like, bullet journal inspirational content I consume on the internet [laughs]. I have tried and failed many a time to have more frequency in that way. But, I don't know, I think it almost just, like, sets me up for failure [laughs] because I have these expectations. And that's, like, the other thing. It's like, you can't force learning necessarily. I don't know if this is, like, a strategy, but I think there is some amount of, like, making sure that I'm in the right headspace for it and, you know, like, my environment, too, kind of is conducive to it. Like, I have, like, the time, right? If I'm trying to squeeze in, I don't know, maybe, like, in between meetings, 20 minutes to be like, what did I learn from this experience? Nothing's coming out [laughs]. That was another thing that I was kind of mulling over when he had this topic proposed is this idea of, like, mindset and environment being really important because you know when you are saying, like, not all time is created equal, and I suspect that if, you know, either you or, like, the people around you and the environment you're in is not also facilitating growth, and, like, how much can you really expect for it to be happening? JOËL: I mean, that's really interesting, right? The impact of sort of a broader company culture. And I think that definitely can act as a catalyst for growth, either to kind of propel you forward or to pull you back. I want to dig into a little bit something you were saying about being in the right headspace to capture ideas. And I think that there's sort of almost, like, two distinct phases. There's the, like, capturing data, and information, and experiences, and then, there's synthesizing it, turning information into learning. STEPHANIE: Yes. JOËL: And it sounds like you're making a distinction between those two things, specifically that synthesis step is something that has to happen separately. STEPHANIE: Ooh, I don't even...I don't know if I would necessarily say that I'm only talking about synthesis, but I do like that you kind of separated those categories because I do think that they are really important. And they kind of remind me a lot about the scientific method a little bit where, you know, you have the gathering data and, like, observations, and you have, you know, maybe some...whatever is precipitating learning that you're doing maybe differently or new. And that also takes time, I think, or intention at least, to be like, oh, do I have what I need to, like, get information about how this is going? And then, yeah, that synthesis step that I think I was talking about a little bit more. But I don't think either is just automatic. There is, I think, quite a bit of intention involved. JOËL: I think maybe the way I think about this is colored by reading some material on the Zettelkasten method of note-taking, which splits up the idea of fleeting notes and literature notes, which are sort of just, like, jotting down ideas, or things you've seen, things that you've learned, maybe a thought you had when you read a particular paragraph in a blog post, something like that. And then, the permanent notes, which are more, like, fully formed thoughts that arise out of the more fleeting ones. And so, the idea is that the fleeting ones maybe you're taking those in a notebook if you're doing it pen and paper. You could be doing it in some sort of, like, daily note, or something like that. And then, those are temporary. They were there to just capture information. Later on, you process that, and then you can throw them out if you need to. STEPHANIE: Yeah, that makes a lot of sense. This has actually been a shift for me, where I used to rely a lot more on memory and perhaps, like, didn't have a great system for taking things like fleeting notes and, like, documenting kind of [inaudible 18:28] what I was saying earlier about how do I make sure that the information is recorded, you know, for me to synthesize later? And I have found a lot more success lately in that fleeting note style of operating. And thanks to Obsidian honestly, now it's so easy to be like, oh, I'm just going to open a quick new file. And I need as little friction as possible to, like, put stuff somewhere [laughs]. And, actually, I'm excited to talk a little bit more about this with you because I think you're a little bit different where you somehow find the time [laughs] and care to create your diagrams. I'm like, if I can, for some reason, even get an Obsidian file open, I'll tab to Slack. And I send myself a lot of notes in my just own personal DM space. In fact, it's actually kind of embarrassing because I use the Command+K shortcut to navigate to my own personal DMs, which you can get to by typing me, like, M-E. And sometimes I've accidentally just entered that into a channel chat [laughs], and then I have to delete it really quick later when I realize what I've done. So, yeah, like, I meant to navigate to my personal notes, and I just put in our team chat, "Me [laughs]." And, I don't know, I have no idea how that comes up [laughs], what people think is going on. But if anyone's listening to this podcast from thoughtbot and has seen that of me, that's what happened. JOËL: You may not be the only one who's done that. STEPHANIE: Thank you. Yeah [laughs], that's good to know. JOËL: I want to step back a little bit because we've been talking about, like, introspection, and synthesis, and finding moments to capture information. And I think we've sort of...there's an unspoken assumption here that a way to kind of turbocharge learning from day-to-day experience is some form of synthesis or self-reflection. Would you agree with that statement? STEPHANIE: Okay. This is another thing that I am perhaps, like, still trying to figure out, and we can figure it out together, which is separating, like, self-driven learning and, like, circumstance-driven learning. Because it's so much easier to want to reflect on something and find time to be, like, oh, like, how does this kind of help my goals or, like, what I want to be doing with my work? Versus when you are just asked to do something, and it could still be learning, right? It could still be new, and you need to go do some research or, you know, play around with a new tool. But there's less of that internal motivation or, like, kind of drive to integrate it. Like, do you have this distinction? JOËL: I've definitely noticed that when there is motivation, I get more out of every hour of work that I put in in terms of learning new things. The more interest, the more motivation, the more value I get per unit of effort I put in. STEPHANIE: Yeah. I think, for me, the other difference is, like, generative learning versus just kind of absorbing information that's already out there that someone else's...that is kind of, yeah, just absorbing rather than, like, creating something new from, like, those connections. JOËL: Ooh. STEPHANIE: Does that [chuckles] spark something for you? JOËL: The gears are turning in my head because I'm almost hearing that as, like, a passive versus active learning thing. But just sort of like, I'm going to let things happen to me, and I will come out of that with some experience, and something is going to happen. Versus an active, I am going to, like, try to move in a direction and learn from that and things like that. And I think this maybe connects back to the original question. Maybe this sort of, like, checking in at the end of the week, taking notes is a way to convert something that's a bit more of a passive experience, spending four days a week doing a project for a client, into something that's a little bit of a more active learning, where you say, "Okay, I did four weeks of this particular type of Rails work. What do I get out of it? What have I learned? What is something new that I've seen? What are some opinions I have formed, patterns I like or dislike?" STEPHANIE: Yeah, I like that distinction because, you know, a few weeks ago, we were at RailsConf. We had kind of recapped it in a previous episode. And I think we had talked about like, oh, do we, like, to sit in talks or participate in workshops? And I think that's also another example of, like, passive versus active, right? Because I 100%, like, don't have the same type of learning by just, you know, listening to a talk that I do with maybe then going to look up, like, other things this person has put out in the world, finding them to talk to them about it, like, doing something with the content, right? Otherwise, it's just like, oh yeah, I heard this talk. Maybe one day I'll remember it when the need arises [laughs]. I, like, have a pointer to it in my brain. But until then, it probably just kind of, like, sits there, and nothing's really happened with it. JOËL: I think maybe another thing that's interesting in that passive versus active distinction is that synthesis is inherently an act of creation. You are now creating new ideas of your own rather than just capturing information that is being thrown at you, either by sitting in a talk or by shipping tickets. The act of synthesizing and particularly, I think, making connections between ideas, either because something that, let's say you're in a talk, a speaker said that sparks an idea for yourself, or because you can connect something that speaker said with another idea that you already have or an idea that you've seen elsewhere. So, you're like, oh, the thing this person is saying connects to this thing I read in a book or something another speaker said in an earlier session, or something like that. All of a sudden, now you're creating these new bits of knowledge, new perspectives, maybe even new mental models. We talked about mental models last week. And so, knowledge is not just the facts that you absorb or memorize. A lot of it is building the connections between those facts. And those are things that are not always given to you. You have to create them yourself. STEPHANIE: Yeah, I am nodding my head a lot because that's resonating with, like, an experience that I'm having kind of coaching and mentoring a client developer on my team who is earlier in her career. And one thing that I've been really, like, working on with her is asking like, "Oh, like, what do you think of this?" Or like, "Have you seen this before? What are your reactions to this code, or, like this comment?" or whatever. And I get the sense that, like, not a lot of people have prompted her to, like, come up with answers for those kinds of questions. And I'm really, really hopeful that, like, that kind of will help her achieve some of the goals that she's, like, hoping for in terms of her technical growth, especially where she's felt like she's stagnated a little bit. And I think that calls back really well to what you said at the beginning of, like, you can spend years, right? Just kind of plugging away. But that's not the same as that really active growth. And, again, like, that's fine if that's where you're at or want to be at for a little while. But I suspect if anyone is kind of, like, wondering, like, where did that time go [laughs]...even for me, too, like, once someone started asking me those questions, I was like, oh, there's still so much to figure out or explore. And I think you're actually really good at doing that, asking questions of yourself. And then, another thing that I've picked up from you is you ask questions about, like, what are questions other people would have? And that's a skill that I feel like I still have yet to figure out. I'm [chuckles] curious what you think about that. JOËL: That's interesting because that kind of goes to another level. I often think of the questions other people would have from a more, like, pedagogical sense. So, I write a lot of blog posts. I write a lot of talks that I give. So, oftentimes when I'm creating that kind of material, there's a bit of an inner critic who's trying to, you know, sitting in the audience listening to myself speak, and who's going to maybe roll their eyes at certain points, or just get lost, or maybe raise their hand with a question. And that's who I try to address those things so that then when I go through it the next time, that inner critic is actually feeling engaged and paying attention. STEPHANIE: Do you find that you're able to do that because you've seen that happen enough times where you're like, oh, I can kind of predict maybe what someone might feel confused about? I'm curious, like, how you got from being, like, well, I know what I would be confused about to what would someone else be unsure or, like, want more information about. JOËL: Part of the answer there is that I'm a very harsh critic myself. STEPHANIE: [laughs] Yes. JOËL: So, I'm sitting in somebody else's talk, and there are probably parts where I'm rolling my eyes or being like, wait a minute, how did you get from this idea to this other thing? That doesn't follow. And so, I try to turn that back towards myself and use that as fuel to make my own work better. STEPHANIE: Yeah, that's cool. I like that. Even if it's just framed as, like, a missed opportunity for people to have better or more comprehensive understanding. I know that's something that you're, like, very motivated to help kind of spread more of [laughs]. Understanding and learning is just important to you and to me. So, I think that's really cool that you're able to find ways to do that. JOËL: Well, you definitely want to, I think, to keep a sort of beginner's mindset for a lot of these things, and one of the best ways to do that is to work with beginners. So, I spent a lot of time, back in the day, for example, in the Elm language chat room, just helping people answer basic questions, looking up documentation, explaining sort of basic concepts. And that, I think, helped me get a sense of like, where were newcomers to the language getting stuck? And what were the explanations of those concepts that really connected? Which I could then translate into my work. And I think that that made me a better developer and helped me build this, like, really deep understanding of the underlying concepts in a way that I wouldn't have had just writing code on my own. STEPHANIE: Wow, forum question answering hero. I have never thought to do that or felt compelled to do that. But I remember my friend was telling me, she was like, "Yeah, sometimes I just want to feel good about myself. And I remember that I know things that other people, like, are wanting to find out," and she just will answer some easy questions on Stack Overflow, you know, about, like, basic Rails stuff or something. And she is like, "Yeah, and that's doing my good deed [laughs]." And yeah, I think that it also, you know, has the same benefits that you were just saying earlier about...because you want to be helpful, you figure out how to actually be helpful, right? JOËL: There's maybe a sense as well that helping others, once more, forces you into more of an active mindset for growth in the same way that interrogating yourself does, except now it's a beginner who's interrogating you. And so, it forces you to think a little bit more about those whys or those places where people get stuck. And you've just sort of assumed it's a certain way, but now you have to, like, explain it and really get into some of the concepts. STEPHANIE: So, on the show, we've talked a lot about the fun things you share in the dev channel in our Slack workspace. But I recently discovered that someone (Was it you?) created an Obsidian MD channel for our favorite note-taking software. And in it, you shared a really cool tool that is available in Obsidian called mind maps. JOËL: Yeah, so mind maps are a type of diagram. They're effectively a tree structure, but they don't really look like that when you draw them out. You start with a sort of topic in the center, and then you just keep drawing branches off of that, going every direction. And then, maybe branches off branches and keep going as you add more content. Turns out that Mermaid.js supports mind maps as a graph type, and Obsidian embeds Mermaid diagrams. So, you can use Mermaid's little language to express a mind map. And now, all of a sudden, you have mind mapping as a tool available for you within Obsidian. STEPHANIE: And how have you been using that to kind of process and experience or maybe, like, end up with some artifacts from, like, something that you're just doing in regular day-to-day work? JOËL: So, kind of like you, I think I have the aspiration of doing some kind of, like, daily note journaling thing and turning that into bigger ideas. In practice, I do not do that. Maybe that's the thing that I will eventually incorporate into my practice, but that's not something that I'm currently doing. Instead, a thing that I've done is a little bit more like you, but it's a little bit more thematically chunked. So, for example, recently, I did several weeks of work that involved doing a lot of documentation for module-level documentation. You know, I'd invested a lot of time learning about YARD, which is Ruby's documentation system, and trying to figure out, like, what exactly are docs that are going to be helpful for people? And I wanted that to not just be a thing I did once and then I kind of, like, move on and forget it. I wanted to figure out how can I sort of grow from that experience maximally? And so, the approach I took is to say, let's take some time after I've completed that experience and actually sort of almost interrogate it, ask myself a bunch of questions about that experience, which will then turn into more broad ideas. And so, what I ended up doing is taking a mind-mapping approach. So, I start that center circle is just a circle that says, "My experience writing docs," and then I kind of ring it with a series of questions. So, what are questions that might be interesting to ask someone who just recently had experience writing documentation? And so, I come up with 4,5,6 questions that could be interesting to ask of someone who had experience. And here I'm trying to step away from myself a little bit. And then, maybe I can start answering those questions, or maybe there are sub-questions that branch off of that. And maybe there are answers, or maybe there are answers that are interesting but that then trigger follow-up questions. And so I'm almost having a conversation with myself and using the mind map as a tool to facilitate that. But the first step is putting that experience in the center and then ringing it with questions, and then kind of seeing where those lead. STEPHANIE: Cool. Yeah, I am, like, surprised that you're still following that thread because the module docs experience was quite a little bit a while ago now. We even, you know, had an episode on it that I'll link in the show notes. How do you manage, like, learning new things all the time and knowing what to, like, invest energy and attention into and what to kind of maybe, like, consider just like, oh, like, I don't know, that was just an experience that I had, and I might not get around to doing anything with it? JOËL: I don't know that I have a great system. I think sometimes when I do, especially a more prolonged chunk of time doing a thing, I find it really worthwhile to say, hey, I don't want that to sort of just be a thing that was in my memory, and then it moves out. I'd like to pull out some more maybe practical or long-term ideas from it. Part of that is capture, but some of that is also synthesis. I just spent two weeks or I just spent a month using a particular technology or doing a new kind of task. What do I have to show for it? Are there any, like, bigger ideas that I have here? Does this connect with any other technologies I've done or any other ideas or theories? Did I come up with any opinions? Did I like this technology? Did I not? Are there elements that were inspirational? And then capturing some of that eventually with the idea of...so I do a sort of Zettelkasten-style permanent note collection, the idea to create at least a few of those based off of the experience that I can then connect to other things. And maybe it eventually turns into other content. Maybe it's something I hold onto for a while. In the case of the module docs, it turned into a Bike Shed episode. It also turned into a blog post that was published this past week. And so, it does have a way of coming back. STEPHANIE: Yeah. Yeah. One thing that sparked for me was that, you know, you and I spend a lot of time thinking about, like, the practice of writing software, you know, in the work we do as consultants, too. But I find that, like, you can also apply this to the actual just your work that you are getting paid for [laughs]. This was, I think, a nascent thought in the talk that I had given. But there's something to the idea of, like, you know, if you are working in some code, especially legacy code, for a long time, and you learn so much about it, and then what do you have to show for it [chuckles], you know? I have really struggled with feeling like all of that work and learning was useful if it just, like, remains in my memory and not necessarily shared with the team or, I don't know, just, like, knowing that if I leave, especially since I am a contractor, like, just recognizing that there's value in being like, oh, I spent an hour or, like, half a day sifting through this complex legacy code just to make, like, a small change. But that small change is not the full value of all of the work that I did. And I suspect that, like, just the mind mapping stuff would be really interesting to apply to more. It's not, like, just practical work, but, like, more mundane, I don't know, like, labor [laughs], if you will. JOËL: I can think of, like, sort of two types of knowledge that you can take out of something like that. Some of it is just understanding how this legacy system works, saying, oh, well, they have this user model that's connected to this old persona table, which is kind of unused, but we sometimes rely for in this legacy case. And you've got to have this permission flag turned on and, like, all those things that you had to just discover by reading the code and exploring. And that's going to be useful to you as long as you work in that legacy codebase, as long as you work through that path. But when you move on to another project, that knowledge probably doesn't serve you a whole lot. There are things that you did throughout that journey, though, that you can probably pull out that are going to be useful to you on other projects. And that might be maybe you came up with a new way of navigating the code or a new way of, like, finding how different pieces were connected. Maybe it was a diagramming tool; maybe it was some sort of gem. Maybe it was just a, oh, a heuristic, like, when I see a model, I like to follow the associations first. And I always go for the hasmanys over the belongstos because those generally lead me in the right direction. Like, that's really interesting insight, and that's something that might serve you on a following project. You can also pull out bigger things like, are there refactoring techniques that you experimented with or that you learned on this project that you would use again elsewhere? Are there ways of maybe quarantining scary code on a legacy project that are a thing that you would want to make more consistent part of your practice? Those are all great things to pull out of, just a like, oh yeah, I did some work on a, like, old legacy part of an app. And what do I have to show for it? I think you can actually have a lot to show for it. STEPHANIE: Yeah, that's really cool. That sounds like a sure way of multiplying the learning. And I think I didn't really consider that when I was first talking about it, too. But yeah, there are, like, both of those things kind of available to you to, like, learn from. Yeah, it's like, that time is never just kind of, like, purely wasted. Oh, I don't know, sometimes it really feels like that [laughs] when you are debugging something really silly. But yeah, like, I would be interested in kind of thinking about it from both of those lenses because I think there's value in what you learn about that particular system in that moment of time, even if it might not translate to just future works or future projects. And, like, that's something that I think we would do better at kind of capturing, and also, there's so much stuff, too, kind of to that higher level growth that you were speaking to. JOËL: I think some of the distinctions we're talking about here is something that was explored in an older episode on note-taking with Amanda Beiner, where we sort of explored the difference between exploratory notes, debugging notes, idea notes, and how note-taking is not a single thing. It can serve many purposes, and they can have different lifespans. And those are all just ways to aid your thinking. But being maybe aware of the kind of thinking that you're trying to do, the kind of notes you're trying to take can help you make better use of that time. STEPHANIE: I have one last question for you before we wrap up, which is, do you find, like, the stuff we're talking about to be particularly true about software development, or it just happens to be the thing that you and I both do, and we also love to learn, and so, therefore, we are able to talk about this for, like, 50 minutes [laughs]? Are you able to make any kind of distinction there, or is it just kind of part of pedagogy in general? JOËL: I would say that that sort of active versus passive thing is a thing that's probably true, just about anything that you do. For example, I do a lot of bouldering. Just going spending a lot of time on the wall, climbing a lot; that's going to help me get better. But a classic way that people try to improve is filming themselves or having a friend film themselves, and then you can look at it, and then you evaluate, oh, that's what I did. This is where I was struggling to get the next hold. What if I try to do something different? So, building in an amount of, like, self-reflection into the loop all of a sudden catalyzes that learning and helps you grow at a rate that's much more than if you're just kind of mindlessly putting time into it. So, I would go so far as to say that self-reflection, synthesis—those are all things that are probably going to catalyze growth in most areas of your life if you're being a little bit more self-aware. But I've found that it's been particularly useful for me when it comes to trying to get better at the job that I do every week. STEPHANIE: Yeah, I think, for me, it's like, yeah, getting better at being a developer rather than being, you know, a software developer at X company. Like, not necessarily just getting better at working at that company but getting better at the skill itself. JOËL: And those two things have a way of sort of, like, folding back into themselves, right? If you're a better software developer in general, you will probably be a better developer at that company. Yes, you want domain knowledge and, like, a deep understanding of how the system works is going to make you a better developer at that company. But also, if you're able to find more generic approaches to onboard onto new things, or to debug more effectively, or to better read or understand unknown code of high complexity, those are all going to make you much better at being a developer at that company as well. And they're transferable skills, so they're all really good things to have. STEPHANIE: On that note. Shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

In this episode, Robby welcomes Robin Heinze, Director of Engineering at Infinite Red, to discuss the intricacies of building and maintaining robust software systems. Key topics covered include:Characteristics of Maintainable Software: Robin shares insights from her team on what makes software maintainable, emphasizing the need for clear documentation, robust setup scripts, and ongoing code refinement.Technical Debt: They delve into managing technical debt, particularly in a consultancy setting, and how to balance client expectations with software quality.React Native: Robin explains the advantages of using React Native for cross-platform development, highlighting its efficiency and accessibility to a broader range of developers.Consultancy Challenges: The conversation also covers the unique aspects of working in a consultancy, including how to embed standards while respecting client processes.Major Takeaways:Effective communication and a proactive approach to maintenance are crucial in software development.Visual elements like graphics can significantly enhance the accessibility and appeal of open source projects.Book Recommendation:A Thursday Murder Club Mystery Series by Richard OsmanHelpful Links:React NativeInfinite RedChain React ConferenceReact Native Radio PodcastFor more insights, make sure to follow Robin on: LinkedInTwitterThanks 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 soon, 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! 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 welcomes Scott Hanselman, VP of Developer Community at Microsoft and host of the Hanselminutes Podcast, to discuss the emotional side of maintainable software. Scott shares his thoughts on fear as a common thread in poorly maintained software, the importance of building a team culture of trust, and how finding a good work-life balance helps create better software.The Role of Fear in Technical DebtScott believes that if you fear the software you work on, it's a tell-tale sign that it has maintainability issues.Technical debt is rooted in fear--either fear of making a change that will break something or fear of being unable to change something when needed.He encourages teams to talk openly about their fears and anxieties regarding the software and to consider what things give them confidence in the codebase.Building a Team Culture of ConfidenceScott emphasizes the importance of empathy in overcoming technical debt and making software more maintainable.Senior engineers and team leads have a responsibility to make junior developers feel safe enough to speak up and ask questions.He advocates for providing new hires with small, achievable tasks to build their confidence and trust in the software.Scott encourages teams to use "inner loop" and "outer loop" thinking.Inner loop - The cycle of making a change, hitting f5, and seeing changes immediately.Outer loop - Things like deploying the codebase, getting it tested, ensuring production stability.Both experienced and junior engineers have their own inner and outer loops as individuals, and continuous improvement at all levels is key.Overcoming Fear, Embracing Maintainability, and Finding BalanceScott shares stories about Microsoft's journey with open-source software and how that process has shaped the company's culture around maintainable code.He talks about the importance of striking a balance between source-opened and open-source software and finding the sweet spot for a project or organization.Scott warns against the trap of striving for unattainable perfection. Aiming for good, solid repeatable work over perfection ultimately yields better results.He uses his own projects, like the Hanselminutes podcast, as examples of focusing on consistent outputs and utilizing a simple workflow.Scott advocates for using AI tools to transcribe coding sessions, freeing up developers from extensive note-taking.Book Recommendation:The Daily Stoic By Ryan HolidayScott Hanselman - Personal WebsiteHanselminutes Podcast.NET Open Source History: .NET Core | Microsoft LearnHelpful Links:Scott Hanselman - Personal WebsiteHanselminutes Podcast.NET Open Source History: .NET Core | Microsoft LearnThanks 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 soon, 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! 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 chats with Stig Brautaset, Staff Software Engineer at CircleCI. Stig shares his insights on maintaining well-documented but complex legacy code, the impact of team dynamics on software maintenance, and his experiences with the SBJSON library.Stig discusses the characteristics of well-maintained software, emphasizing the importance of team experience, domain knowledge, and risk appetite. He reflects on his own career journey, highlighting the transition from overconfidence to a balanced approach to risk-taking.A significant portion of the conversation delves into Stig's concept of "Alien Artifacts," which describes highly resistant legacy code written by highly skilled engineers. He explains the challenges of modifying such code and shares examples from his own experiences.Stig also talks about his work on the SBJSON library, addressing the complexities of handling multiple versions and dependency conflicts. He advocates for developers maintaining the software they ship and discusses the balance between shipping features quickly and maintaining long-term code quality.Key TakeawaysThe influence of team dynamics on software maintenanceUnderstanding the concept of "Alien Artifacts" in legacy codeStrategies for handling multiple versions of a software libraryThe importance of developers being on call for the software they shipManaging different types of technical debtBook Recommendation:The Scout Mindset by Julia GalefStig Brautaset on LinkedInAlien Artifacts Blog PostSBJSON Library CircleCIThe Confident Commit PodcastHelpful Links:Stig Brautaset on LinkedInAlien Artifacts Blog PostSBJSON Library CircleCIThe Confident Commit PodcastWant to share your thoughts on this episode? Reach out to Robby at robby@maintainable.fm.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 soon, 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! 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.

Join Robby as he welcomes Brit Myers to the podcast. Brit, currently thriving as the VP of Engineering at System Initiative, discusses the intricacies of maintaining software. She emphasizes the importance of navigable software, where the ease of tracing the code and understanding its structure is paramount. Brit highlights the significance of clear naming conventions and inline documentation, as they help in maintaining a cohesive narrative within the software. The conversation touches on the challenges posed by discrepancies in vocabulary between product management and engineering, and how glossaries can bridge these communication gaps. Brit advocates for the use of glossaries more as a reflective tool rather than a proactive one, given the dynamic nature of software development. She also delves into strategies for managing legacy code and technical debt, proposing a pragmatic approach where wrapping and modularizing legacy components can mitigate risks. She discusses the balance between immediate feature delivery and long-term code health, stressing the importance of aligning technical risks with business objectives. The episode explores the impact of company culture on development practices, the benefits of synchronous work environments, and the evolving landscape of DevOps. Tune in to tap into Brit's valuable wisdom.Book Recommendation:Crucial Conversations: Tools for Talking When Stakes are High By Kerry Patterson, Stephen R. Covey, Joseph Grenny, Ron McMillan, and Al SwitzlerHelpful Links:System InitiativeBrit on LinkedInSPACE FrameworkDORA metricsThanks 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 soon, 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! 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.

Welcome back! In our ongoing discussion on improving life and technology, today's focus is on a more dramatic scenario: saving customers from potential disaster due to legacy code. When does legacy code need to be retired, and what signs indicate it's time for a major overhaul? We'll dive into these questions through real-world examples and expert insights. Listen to Rob and Michael Discuss ways to Deal with Legacy Code The Legacy Code Conundrum Legacy code refers to outdated software that still performs necessary functions but is based on old technology. The core question is: when does maintaining legacy code become impractical or even risky? Our host recounted an experience with a client who had a custom application built on the Eclipse foundation RCP with additional dependencies like Adobe Flash. When the host encountered this system in 2021-22, the last update to the code had been in 2014. The application's underlying technology was so outdated that it was incompatible with modern systems. This scenario is not unique; many organizations rely on aging software that becomes increasingly difficult to maintain as technology evolves. The Case Study: A Ten-Year-Old Application In the host's case study, the client's custom application was built on an old version of Java and Eclipse, using technologies like Flash that are no longer supported. The application worked fine until system upgrades rendered it inoperable. Initially running on multiple machines, the application was eventually down to a single operational machine. This machine was critical: if it failed, the entire application would be lost. Despite having the source code, the modernization process was fraught with challenges. The task involved updating libraries, replacing deprecated technologies, and rewriting significant portions of the code. After six months of effort, it became clear that a complete rewrite was necessary. The core JDBC connections were outdated and incompatible with modern systems, necessitating a significant redevelopment effort. When to Rewrite: Key Considerations Technology Obsolescence: If the technology stack is no longer supported, it's a red flag. Modernizing might involve not just updates but a full-scale rewrite. Compatibility Issues: New system upgrades may not support old applications. As seen in the host's example, upgrading to a newer operating system rendered the application unusable. Developer Expertise: Often, the original developers are no longer available, and current teams may lack the knowledge to maintain or update the legacy code effectively. Cost and Risk: Maintaining old code can be costlier and riskier than starting anew. Constant patching can introduce new bugs, and outdated software may pose security risks. The Modernization Approach The podcast highlighted the importance of understanding the existing system and planning a phased approach to modernization: Assessment: Conduct a thorough assessment of the current system, identifying critical components and dependencies. Determine what can be salvaged and what needs replacement. Data Migration: Plan for data migration from the old system to the new. This may involve extracting data manually or through automated scripts. Incremental Development: Instead of a big-bang approach, develop the new system in phases. This allows for continuous integration and testing, reducing the risk of total failure. User Experience: Consider whether the new system needs to replicate the old user experience or if a new, modern interface would be more beneficial. Real-World Challenges Michael, the co-host, shared his current project in the healthcare sector involving an old IBM AS/400 system. This green-screen, keyboard-driven application was solid but outdated. Key challenges included integration with unsupported systems and the need for continuous deployment and integration. Legacy systems often lack clear documentation, making it hard to understand their full functionality. Moreover, integration points with other outdated applications can further complicate the modernization effort. For Michael's client, the healthcare application was crucial for billing and patient information management, making its stability and modernization a high priority. Modernizing Legacy Code Modernizing legacy code is often more practical and safer than maintaining outdated systems. By assessing the current state, planning data migration, and developing incrementally, organizations can ensure a smoother transition. The goal is not just to replace old technology but to build a robust, modern solution that can evolve with future technological advancements. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Code Refactoring: Maintaining Clean, Efficient Code Deciphering Code Chaos: Strategies for Writing Maintainable Code Code Reviews Make Better Developers – Interview With Phil Alves Behind the Scenes Podcast Video

In this episode, Robby interviews Andrea Guarino, a Software Engineer at Sonar, about the importance of leveraging static analysis tools for maintaining clean and adaptable code. Andrea emphasizes that well-maintained software should be easy to change, consistent, intentional, and responsible. He explains that static analysis tools play a crucial role in identifying potential issues, ensuring code quality, and preventing security leaks. Andrea also highlights the importance of educating developers on these best practices and integrating such tools into the development workflow to uphold a high standard of code quality. He discusses the challenges of maintaining consistency in code, especially when dealing with legacy code written in different periods and by different teams. Andrea also touches on the concept of technical debt, suggesting a pragmatic approach to address it by balancing between new code quality and gradual improvements to legacy code. Stay tuned for that and more!Book Recommendation:The Brothers Karamazov by Fyodor DostoevskyHelpful Links:Andrea on LinkedInSonarPersonal WebsiteThanks 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 soon, 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! 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.