Skip to Content

DHH: Celebrating Legacy Software as a Victory and the Story of How Humans Can't Estimate

EP-108 | October 4, 2021 | 53:16 | Last updated: November 17, 2023

Legacy Code Engineering Culture

David Heinemeier Hansson

Co-founder & CTO, 37signals

Creator of Ruby on Rails and co-founder of 37signals (Basecamp, HEY). Author of 'Rework' and 'It Doesn't Have to Be Crazy at Work'.

Robby speaks with David Heinemeier Hansson (aka DHH), Creator of Ruby on Rails and CTO of Basecamp / HEY.

Disclaimer: Robby sat down with DHH in early March 2021 about ~5-6 weeks before Basecamp's policy changes were announced and the significant impact that had within our community. It's quite likely that some of Basecamp's internal software engineering processes have since changed.

In an enthralling episode of Maintainable, host Robby is joined by David Heinemeier Hansson (DHH), the original brain behind Ruby on Rails and the CTO of Basecamp & Hey. They embark on a deep exploration of the software world, challenging conventional views and celebrating the often underappreciated aspects of software development.

The discussion kicks off with a refreshing perspective on legacy software. DHH and Robby delve into why legacy software should be celebrated as a victory, a testament to its success and durability in a fast-evolving tech landscape. This sets the stage for a broader conversation about the lifecycle and evolution of software products.

They then shift gears to Basecamp's approach to versioning their SaaS products. Unlike the common industry trend of continuous iteration on a single version, Basecamp has made strategic choices to release new versions, a decision rooted in their unique business and product philosophy. This leads to an insightful discussion on how Basecamp handles the balance between innovation and maintenance, including the management of security backports and the upkeep of their software.

DHH introduces listeners to the concept of ShapeUp, Basecamp/HEY's innovative approach to project management. He explains how their team uses two-week cooldown periods to manage bugs and follow-up work, ensuring that the development process remains agile and responsive to emerging needs.

The conversation also delves into the specialized teams at Basecamp, such as the Security Infrastructure Performance (SIP) team, which plays a crucial role in addressing security concerns and handling reactive work. This is juxtaposed with the Research & Fidelity team's focus on building and extracting frameworks, highlighting the diverse strategies employed to maintain and evolve a robust software environment.

A significant portion of the discussion revolves around Ruby on Rails. DHH shares why a major rewrite of Rails has never been necessary, attributing it to the framework's solid foundation and continuous improvement. He also sheds light on the types of testing that provide the most value in their Ruby on Rails applications and offers a candid take on Test-Driven Development (TDD).

Finally, DHH and Robby discuss the importance of budgeting time and resources in software projects, contrasting it with traditional estimating methods. They conclude with a discussion on the competitive advantage of Ruby on Rails in the current technology landscape and why it's perfectly fine that Rails isn't always the center of tech conversations anymore.

Book Recommendation: "The Manual" by Epictetus

Helpful Links

Subscribe to Maintainable on:

Or search "Maintainable" wherever you stream your podcasts.

Frequently Asked Questions

What does DHH think about legacy software?

DHH views legacy software as a victory, not a burden. If software has been running for years, it means it has been delivering value. He encourages teams to celebrate long-running systems rather than treating them as problems to solve.

Why does DHH say humans can't estimate software projects?

DHH argues that software estimation is fundamentally broken because development involves too many unknowns. He recommends working in small batches and shipping frequently instead of trying to predict timelines accurately.

What is DHH's approach to technical debt?

DHH suggests that not all technical debt needs to be paid down. Some debt is acceptable if the software continues to deliver value. He recommends pragmatic decisions over perfectionism.

🎧 Listen from Anywhere 🪐

Listen on all the major podcast platforms.

Between the episodes

223 Episodes published since 2019

Stay sharp. Skip the noise.

One email when a new episode drops. That's it.

Joined by engineering leaders at companies you've heard of.