Re:Ask HN: Rewrite or Refactor?
by surprisetalk on Tuesday January 03, 2023 @07:16AM
(#34230523)
I tend to favor rewrites over refactors for two reasons:
1. Writing code is easier than reading code.
2. When a team is "scared" of their codebase, everybody becomes frustrated and confused and nobody takes responsibility for anything.
The difficult question is _how_ to rewrite. Here are some strategies I've seen in the past:
- The "slow" rewrite: Rewrite a chunk of the code that can be completely rewritten in 2 weeks. Deploy tiny rewrites alongside everything else. New code should not reference _any_ code from the old codebase. Do not try to fix anything in the old codebase.
- The "frodo" rewrite: Ask 2-3 devs to go off on an adventure and rewrite the entire app from scratch while the rest of the team maintains the existing app.
- The "YOLO" rewrite: Give the whole team 3 weeks to rewrite the entire thing from scratch. Put 1-3 devs on "cleanup" duty, where they polish and test the YOLO code before release. Also consider doing some group "bug bashes".
1. Writing code is easier than reading code.
2. When a team is "scared" of their codebase, everybody becomes frustrated and confused and nobody takes responsibility for anything.
The difficult question is _how_ to rewrite. Here are some strategies I've seen in the past:
- The "slow" rewrite: Rewrite a chunk of the code that can be completely rewritten in 2 weeks. Deploy tiny rewrites alongside everything else. New code should not reference _any_ code from the old codebase. Do not try to fix anything in the old codebase.
- The "frodo" rewrite: Ask 2-3 devs to go off on an adventure and rewrite the entire app from scratch while the rest of the team maintains the existing app.
- The "YOLO" rewrite: Give the whole team 3 weeks to rewrite the entire thing from scratch. Put 1-3 devs on "cleanup" duty, where they polish and test the YOLO code before release. Also consider doing some group "bug bashes".