Skip to main content
The Bike Shed

446: All about rewrites

35 min episode · 2 min read
·
Stephanie Eeman,Joel Kenville

Episode

35 min

Read time

2 min

Topics

Design & UX, Software Development, Product & Tech Trends

AI-Generated Summary

Key Takeaways

  • Scope rewrites as refactors: Instead of rewriting entire applications, bound changes to specific subsystems, modules, or classes. This transforms risky rewrites into manageable refactoring work that maintains existing behavior while improving internals, allowing teams to continue shipping features without disruption.
  • The 90% done trap: Development work represents roughly 30% of total effort, while 70% involves handling real user interactions, fixing unexpected bugs, and addressing edge cases discovered in production. Avoid demoing unmerged work or mocked features that create false impressions of progress.
  • Prototype window opportunity: Rewrites make sense for prototypes or proof-of-concept code with no test coverage, corrupted data models, or fundamental architectural flaws. Once real users depend on the application, rewrite costs increase exponentially while business justification decreases proportionally with user base growth.
  • Change in place incrementally: Introduce new architectural components gradually rather than stopping all development for a complete rewrite. Structure changes so each piece delivers immediate value—like making one section faster this week, another next week—rather than requiring full completion before seeing benefits.

What It Covers

Joel and Stephanie examine software rewrite projects, exploring when rewrites make sense versus incremental refactoring, the hidden costs of starting fresh, and strategies for modernizing legacy applications without stopping active development.

Key Questions Answered

  • Scope rewrites as refactors: Instead of rewriting entire applications, bound changes to specific subsystems, modules, or classes. This transforms risky rewrites into manageable refactoring work that maintains existing behavior while improving internals, allowing teams to continue shipping features without disruption.
  • The 90% done trap: Development work represents roughly 30% of total effort, while 70% involves handling real user interactions, fixing unexpected bugs, and addressing edge cases discovered in production. Avoid demoing unmerged work or mocked features that create false impressions of progress.
  • Prototype window opportunity: Rewrites make sense for prototypes or proof-of-concept code with no test coverage, corrupted data models, or fundamental architectural flaws. Once real users depend on the application, rewrite costs increase exponentially while business justification decreases proportionally with user base growth.
  • Change in place incrementally: Introduce new architectural components gradually rather than stopping all development for a complete rewrite. Structure changes so each piece delivers immediate value—like making one section faster this week, another next week—rather than requiring full completion before seeing benefits.

Notable Moment

Joel shares his one regret about arguing against rewriting a prototype with corrupted database triggers and zero test coverage, realizing afterward that the two-week timeline would have delivered more value by rebuilding correctly in Rails from the start.

Know someone who'd find this useful?

Episode Transcript

This episode is brought to you by WorkOS. If you're building a b two b ass app, at some point, your customers will start asking for enterprise features like single sign on, skim, provisioning, role based access control, and audit trails. That's where WorkOS comes in. With ease to use and flexible APIs that help you ship enterprise features on day one without slowing down your core product development. Today, some of the hottest startups in the world are already powered by WorkOS, including ones you probably know, like Perplexity, Vercel, Jasper, and Webflow. WorkOS also provides a generous free tier of up to 1,000,000 monthly active users for its user management solution, making it the perfect authentication and authorization solution for growing companies. It comes standard with rich features like social logins, bot protection, MFA, roles and permissions and more. If you're currently looking to build SSO for your first enterprise customer, you should consider using WorkOS. Integrate in minutes and start shipping enterprise plans today. Check it all out at workos.com. That's workos.com. Hello, and welcome to another episode of The Bike Shed, a weekly podcast from your friends at Thoughtbot about developing great software. I'm Stephanie Eeman. And I'm Joel Kenville. And together, we're here to share a bit of what we've learned along the way. So, Joel, what's new in your world? I recently read an article on configuring capybara, sort of a test UI library that a lot of Rails apps use to interact with end to end tests. And there's a bunch of things that you can configure on it that I didn't realize that will allow its selectors to just pick up things by name. So by default, you can target any form input by the name of its label or its ID or its name attribute. But a common pattern that you'll see in testing is adding a test ID data attribute to Dom elements. And Capybara, like, accepts that that's the thing that people do, wants to make your life easier. So you can say, hey. The test ID attribute in my app is data test ID or my test ID or whatever it is. And then now when you say fill in the username field with Joelle, it will look up things by either label or name or ID or test ID using the attribute that I supplied. So that's got me really excited to dig deeper into Capybara selectors. All that being said, relying on test IDs is a bit of an anti pattern. So I'm sort of like, I'm excited that Capybara can do this, and also you probably shouldn't do it. Yeah. Interesting. So it goes in that order of trying to find whatever element you're selecting on. I don't know what the order is. That's a good question. Yeah. So I was thinking a lot about how React testing library, when I need to do something similar and assert on or find and interact with certain …

Get the full transcript (5,809 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all The Bike Shed transcripts →

You just read a 3-minute summary of a 32-minute episode.

Get The Bike Shed summarized like this every Monday — plus up to 2 more podcasts, free.

Pick Your Podcasts — Free

Keep Reading

More from The Bike Shed

We summarize every new episode. Want them in your inbox?

Similar Episodes

Related episodes from other podcasts

Explore Related Topics

This podcast is featured in Best Cybersecurity Podcasts (2026) — ranked and reviewed with AI summaries.

Read this week's Software Engineering Podcast Insights — cross-podcast analysis updated weekly.

You're clearly into The Bike Shed.

Every Monday, we deliver AI summaries of the latest episodes from The Bike Shed and 192+ other podcasts. Free for one show.

Start My Monday Digest

No credit card · Unsubscribe anytime