What are the key takeaways from this The Bike Shed episode?

Key insights include: **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.

What did Stephanie Eeman and Joel Kenville discuss on The Bike Shed?

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 topics include: **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..

How long is this episode of The Bike Shed?

This episode is 35 minutes long. SignalCast provides an AI-generated summary so you can get the key insights in about 3 minutes.

The Bike Shed

446: All about rewrites

November 12, 2024

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

Published Dec 25, 2025

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?