The code is horrible. Looking at it makes you want to tear your hair out. Something has to be done! The question is, what are you going to do?
You have two options:
- You either rewrite and replace it, building a whole new sub-system which will eventually result in the old version of the code being deleted.
- Or else you refactor it, i.e. applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant. (Refactoring - Improving the Design of Existing Code by Martin Fowler, with Kent Beck)
The question is, which do you pick? Your heart says "Rewrite it, this code is beyond hope!". The internet says "Refactor it, rewriting is evil!". What should you do? The answer is, as it often is, "it depends".
Here are my 10 questions to ask yourself to decide whether to rewrite, or to refactor:
โ | Question | Rewrite | Refactor |
---|---|---|---|
1. | How much time โฐ do you have? If you start rewriting, are you committed to finishing it? | Lots of time | Not a lot of time |
2. | Do you have the right people ๐ฉ๐ปโ๐ป๐จ๐ฝโ๐ป๐ฉ๐ฟโ๐ป๐จ๐ผโ๐ป available to make this change happen? (People with backend/frontend/tech ops etc skills as applicable) | Yes we do | No we don't |
3. | How much of the system as a whole ๐ are you rewriting? | A small part or a specific domain | The whole system or most of it |
4. | What is it about the code that is bad ๐? | The whole design | The way it's written |
5. | How often do you predict ๐ฎ (hopefully know) this code will need to change in the future? | Very often | Not often |
6. | How mission critical and/or valuable ๐ธ is this feature or domain? | Very valuable | Not very valuable |
7. | Do you understand ๐ง the existing code? Do you know in detail what it does? Are the requirements clear? | Yes | No |
8. | Is it just the code that is bad, or do you also need (not just want!) to make changes to the technology stack ๐ค being used? | Technology | Just the code |
9. | If you had to rewrite it, how long will it take you to ship ๐ข the first part of your rewrite to production, with actual people using it? | A few days, a couple of weeks max | Months, or even years |
10. | Why are you doing this? No really: Dig deep and be honest! I'll wait ๐ ๐ป. | I believe this is the best choice | I hate this code & my ego thinks I can do better |
Here's the catch: If at least one of the questions above resulted in you picking an answer in the "refactor" column, hit the brakes on that rewrite! The risk of refactor is much smaller than a rewrite. The cost of a rewrite gone bad are immeasurable.
Does this mean you should never rewrite code? No! What it does mean is that if the conditions are not right you should go back to the drawing board and make do for now until the conditions are right. Sometimes a rewrite is truly the better option, but avoid doing it just because it sounds like the easiest or most appealing.
What do you think? Are there any questions you ask yourself that I have missed?
Originally posted on: https://ericathe.dev/blog/2020/02/27/rewrite-vs-refactor/
Top comments (4)
A good list of questions.
Another thing to note is the interaction of 7 and 9. You have to ask yourself is there a chance you don't understand the code well enough to estimate the amout of work required correctly? Daniel Kahneman, for instance, has written about the tendency to underestimate the amount of work needed to complete a task when it's us doing it.
Joel Spolsky's blog on this topic is worth reading too.
Very good point! This definitely needs a contingency plan for when you think it's going to take you a week and a month later you're still stuck. Somewhere in there I think the sunk cost fallicy comes into play.
Love that post from Joel, had read it ages ago but it definitely still holds true!
thanks for the good read ๐
Thank you for your kind words! ๐