446: All about rewrites

Nov 12, 2024

Delve into the intricacies of software rewrites, exploring when and why they might be necessary. Discover the challenges tied to legacy code, from potential data loss to old bugs reemerging. Learn about balancing business value with developer satisfaction. The conversation also emphasizes the importance of incremental changes over complete rewrites. Plus, hear best practices for testing in both Capybara and React, focusing on accessibility and pragmatic risk management. Get insights that could save your team time and effort!

Ask episode

Chapters

Transcript

Episode notes

Intro

00:00 • 3min

Enhancing Accessibility in Testing with React

03:03 • 2min

Balancing Confidence and Pragmatism in Testing Strategies

05:10 • 3min

Navigating the Risks of Rewriting Legacy Code

08:22 • 17min

Innovation Hurdles: The Role of Existing Code

25:28 • 3min

Navigating Code Rewrites

28:36 • 7min

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