Sign up to save your podcasts
Or
Share 446: All about rewrites
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
446: All about rewrites
When is it time for a rewrite? How do you justify it? If you’re tasked with one, how do you approach it? In today’s episode of The Bike Shed, we dive into the tough question of software rewrites, sharing firsthand experiences that reveal why these projects are often more complicated and risky than they first appear. We unpack critical factors that make or break a rewrite, from balancing developer satisfaction with business value to managing stakeholder expectations when costs and timelines stretch unexpectedly. You’ll hear about real-world rewrite pitfalls like downtime and reintroducing bugs, as well as strategies for achieving similar improvements through incremental changes or refactoring instead. If you’re a developer or team lead considering a rewrite, this conversation offers a pragmatic perspective that could save your team time, effort, and potential setbacks. Tune in to learn how to make the best call for your codebase and find out when a rewrite might actually be necessary!
Key Points From This Episode:
Accessible selectors versus test IDs: best practices in Capybara and React Testing Library.
Balancing test coverage with pragmatism and risk tolerance with Good Enough Testing.
Software rewrites and the tough questions around deciding when they're necessary.
The importance of prioritizing business value over frustrations with the current codebase.
Drawbacks of rewrites, such as downtime, data loss, and reintroducing past bugs.
Risks of “grass is greener” thinking and using mocked data in demos.
Unrealistic expectations of full feature parity and why an MVP approach is better.
How incremental refactoring can achieve similar goals to a complete rewrite.
The appeal and hubris of a “fresh start” and why it’s much more complex than that.
Balancing innovation with practicality: ways to introduce new elements without rewriting.
An example that illustrates when a rewrite might actually be necessary.
Reasons that early prototypes and test builds are the best candidates for rewrites.
Links Mentioned in Today’s Episode:
Mailtrap
WorkOS
Matt Brictson: ‘Simplify your Capybara selectors’
React Testing Library Guidelines
Capybara Accessibility Selectors
Good Enough Testing
‘RailsConf 2023: The Math Every Programmer Needs by Joël Quenneville’
‘Testing Your Edge Cases’
'Working Iteratively'
'Technical Considerations to Help Scale Your Product'
Dan McKinley: ‘Choose Boring Technology'
The Bike Shed
Joël Quenneville on LinkedIn
Joël Quenneville on X
Support The Bike Shed
Support The Bike Shed
View all episodes
By thoughtbot
4.9
121121 ratings
When is it time for a rewrite? How do you justify it? If you’re tasked with one, how do you approach it? In today’s episode of The Bike Shed, we dive into the tough question of software rewrites, sharing firsthand experiences that reveal why these projects are often more complicated and risky than they first appear. We unpack critical factors that make or break a rewrite, from balancing developer satisfaction with business value to managing stakeholder expectations when costs and timelines stretch unexpectedly. You’ll hear about real-world rewrite pitfalls like downtime and reintroducing bugs, as well as strategies for achieving similar improvements through incremental changes or refactoring instead. If you’re a developer or team lead considering a rewrite, this conversation offers a pragmatic perspective that could save your team time, effort, and potential setbacks. Tune in to learn how to make the best call for your codebase and find out when a rewrite might actually be necessary!
Key Points From This Episode:
Accessible selectors versus test IDs: best practices in Capybara and React Testing Library.
Balancing test coverage with pragmatism and risk tolerance with Good Enough Testing.
Software rewrites and the tough questions around deciding when they're necessary.
The importance of prioritizing business value over frustrations with the current codebase.
Drawbacks of rewrites, such as downtime, data loss, and reintroducing past bugs.
Risks of “grass is greener” thinking and using mocked data in demos.
Unrealistic expectations of full feature parity and why an MVP approach is better.
How incremental refactoring can achieve similar goals to a complete rewrite.
The appeal and hubris of a “fresh start” and why it’s much more complex than that.
Balancing innovation with practicality: ways to introduce new elements without rewriting.
An example that illustrates when a rewrite might actually be necessary.
Reasons that early prototypes and test builds are the best candidates for rewrites.
Links Mentioned in Today’s Episode:
Mailtrap
WorkOS
Matt Brictson: ‘Simplify your Capybara selectors’
React Testing Library Guidelines
Capybara Accessibility Selectors
Good Enough Testing
‘RailsConf 2023: The Math Every Programmer Needs by Joël Quenneville’
‘Testing Your Edge Cases’
'Working Iteratively'
'Technical Considerations to Help Scale Your Product'
Dan McKinley: ‘Choose Boring Technology'
The Bike Shed
Joël Quenneville on LinkedIn
Joël Quenneville on X
Support The Bike Shed
Support The Bike Shed
More shows like The Bike Shed
View all
Software Engineering Radio - the podcast for professional software developers
262 Listeners
The Changelog: Software Development, Open Source
285 Listeners
Startups For the Rest of Us
694 Listeners
Giant Robots Smashing Into Other Giant Robots
89 Listeners
Build Phase
45 Listeners
The Ruby on Rails Podcast
53 Listeners
Thoughtworks Technology Podcast
43 Listeners
Reboot
12 Listeners
Tentative
9 Listeners
Software Engineering Daily
630 Listeners
Soft Skills Engineering
271 Listeners
Syntax - Tasty Web Development Treats
985 Listeners
REWORK
212 Listeners
Crossroads
2 Listeners
CoRecursive: Coding Stories
185 Listeners
Remote Ruby
34 Listeners
Practical AI
196 Listeners
Code and the Coding Coders who Code it
6 Listeners
IndieRails
5 Listeners