It’s easier to rewrite something than to figure out what is going wrong.
It’s easier to start from scratch, ignore the history and do it your way.
It’s easier to ignore, then engage.
The decision to rewrite versus fixing a code problem is always rooted in emotion and not the code.
We Can Do It Better
If it’s someone new to the team, their first instinct when this discussion is being raised is to lean towards rewriting it.
Because they don’t need to learn the old code, they don’t need to figure out what is breaking and where and most importantly they don’t need to understand what decisions were taken and why.
In short, hubris has reared it’s ugly head, they’ve scoffed and they know – “I Can do it Better”.
However, in most cases they can’t, they think they can, but once they get into the weeds of it all, they’ll start to hit the same roadblocks that you’ve encountered in building it up.
We Can Do It Better is a path based on pride and over-confidence.
The Technology Factor
Software platforms and frameworks are being updated an increasingly exponential rate. Every day code is changing. What you write today, could be written better 4 – 6 months from now.
Will you be rewriting your code base every 4 – 6 months to take advantage of these new features?
If the reason for your rewrite is to “be on the latest framework” or “take advantage of new patterns” that do not result in significant performance improvements with maintenance time staying the same or (hopefully) decreasing, then there is no value on being on the latest and greatest software.
Creating a Make Work Project
Everyone hits a slow period in their daily grind. Some go on longer than others, but it’s there. And when it happens, the first project to come up is code that “needs” to be rewritten and made better.
If this discussion is coming out of left field with no pre-dating factors associated to it, then you are now part of a “Make Work” project and you do not want to be part of a “Make Work” projects. As the name implies, someone has decided that this is a good idea (but it’s not) and as such they are trying to make work happen in order to look busy.
Make work projects never work, they are never completed, they are never good enough and if you suspect one is happening, you should dump it and focus on finding a Do Work project. Do Work Projects matter, they are needed and are value driven.
There are valid examples of when a code base needs to be written, but this number is much smaller than you think (and the success rate even smaller). If you’re being faced with a decision to rewrite versus fix, take a hard look at the decisions and reasons being used to justify the rewrite – are they emotion based or are they based on delivery and technology patterns.
Moving to the Cloud? That’s a solid reason for a rewrite.
Platform being discontinued? It’s a no-brainer, rewrite it.
Trying to fix a few bugs that are “tricky”?
Take a second look, fixing those 5 bugs will have a much greater ROI (Return on Investment) than rewriting your app.
And if you’re looking for the leadership take on this, apply the above logic to your team – is it better to blow up the team and start from scratch or fix the problem and move on?