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
Tentative
9 Listeners
Software Engineering Radio
273 Listeners
The Changelog: Software Development, Open Source
290 Listeners
Giant Robots Smashing Into Other Giant Robots
88 Listeners
Build Phase
44 Listeners
Software Engineering Daily
625 Listeners
Soft Skills Engineering
283 Listeners
Syntax - Tasty Web Development Treats
986 Listeners
REWORK
210 Listeners
Crossroads
2 Listeners
CoRecursive: Coding Stories
188 Listeners
Remote Ruby
35 Listeners
Practical AI
211 Listeners
Reboot
12 Listeners
Code with Jason
14 Listeners
The Stack Overflow Podcast
62 Listeners
Signals and Threads
72 Listeners
Code and the Coding Coders who Code it
6 Listeners
IndieRails
6 Listeners
The Pragmatic Engineer
64 Listeners