Rewrite or Refactor?

Common scenario: You have a massive legacy app with 1000s of lines of code and millions of little undocumented hacks scattered throughout, 5 years worth of features that originate from customer emails, SMSs, meetings and drunken strip joint napkins, strange Hungarian notation written by mercenary developers from the East, and ancient business analysts who have long since retired and are simply occupying space until their pension comes through. There are no unit tests, no integration tests, spaghetti code, delicate build scripts (if any) and a deployment process that only the guy in the basement with a PHD and a polyphasic sleep cycle can master...

If this sounds familiar, it’s natural to think: “How the hell did this happen?” and most managers and developers do. The problem is not that they dwell on this thought for too long, but not for long enough. The answer to this question is simple, you (or those before you..let’s be honest though, it was you) were lazy.

You may argue that you were under tight deadlines and weren’t given enough time? Lazy excuse. Maybe you didn’t have the knowledge or experience? Lazy. As a dev it’s your responsibility to make it abundantly clear to your managers that you need knowledge, experience and time in order to create a piece of software that is intended to remain in existence for any longer than 2 years. If you don’t have a person on your team with experience — demand one. If you don’t have the knowledge — demand education. If you don’t have enough time — demand more. It’s up to you to convince the God’s above that you are serious, if you can’t well…

If you did all these things and your voice was not heard, find a different place to work. One that will listen. Your resignation is really the only real power you wield over your employer, use it calmly and wisely. Understand and be comfortable with the fact that you are replaceable and will be replaced if you leave. But better that someone else spends the next 2 years of their life beating their head against a wall than you. In the land of milk and honey, well… that’s a foolish prospect.

If you have a code base that resembles a spider web in a thunderstorm, it’s always always always better to rewrite.

But, but, but…

You will lose all those small features that were put in but are now lost to the ages. All the little hacks… what if you miss something?

This is an argument is flawed on so many levels, let’s start at the quickest and most relevant to this article:

If you decide to refactor the code instead of rewrite it, you will have exactly the same problem! If fact anytime you change your spaghetti code, be it a new feature or a bug fix, you run this gauntlet.

Now lets dig a little deeper.

There’s an old saying: you can’t see the forest for the trees. Sure, you might miss a few hacks here and there, but who cares? Right now, it’s taking you an average of 1 month to add a new feature to your house of cards because you can’t do anything to the code without breaking something else, your customers are leaving your website because it only works on Internet Explorer 6 and the users who you’ve tricked into staying by signing an exclusive contract are feeling tricked and are asking their lawyers how to escape because it takes them an hour to make it through your archaic workflow. It can’t get any worse!

Undocumented hacks are an overt admission of the disconnect between your product and it’s users. They are a symptom of a more serious problem: a product management process that is not functioning. Fix the bigger problem and the smaller problems will fix themselves. Surely you have a Product Owner who understands your users right? Why don’t they know about these little undocumented features? And even if you have a lame excuse for not knowing these little things, put it to the scream test. Your users are going to be so thankful for such a clean brand new system that they will over look these little ‘important’ features. More likely these little ‘important’ features were requested to bypass some poorly thought out workflow and are now irrelevant in the new Porsche-like system you have rewritten.

When the customer screams about a missing feature, the first thing you should be thinking is: how important is this customer? If the answer is: not very. Point them in the direction of a competitor. Seriously. Focus on the needs of the users that are bringing in 80% of your revenue and fire the rest if they get all antsy-in-their-pantsy. If they are indeed an important customer, well, if you have rewritten the code properly and cleanly, it shouldn’t be hard to put this missing feature back — in the right spot this time.

Undocumented hacks… if nobody remembers what they were — how do you know they exist? If you show me an example of one of these hacks, I’ll write it down and then I’ll you ask for another example… I’ll repeat this all day and we can add them into the backlog for the rewrite where they will be properly prioritised. If you can’t find 80% them within a day, what happens when you need to change one of these magical hacks in the legacy system? You are going to make the customer wait 2 days while you find it, test it, release it and cross your fingers that it both works and doesn’t bring production to a grinding halt? Really?

It takes too long.

True it will take a long time, it’s a long term investment. But the result is not just a clone. It is cleaner, faster, more responsive, it focuses on your core users, it has far less bugs, it’s stable and most importantly, easier and therefore faster to improve and iterate on.

Refactoring is also a time consuming task, not without risks of its own. If it takes you 3 months to rewrite, it will probably take you (considering that the show must go on) 9 months to refactor. In other words, you can bet your ass that refactoring will eventually take a back seat to feature requests and bug fixes.

We can’t afford to put a feature freeze on our product while the new one is written

Use your imagination man! Why not rewrite the system in parallel? Once you have a new system ready with the MVP features ready to go, release it and tell all your users. I guarantee they will fall over themselves to move to a system with 80% of the features which runs 10x smoother. Once you see this happen, send me a cheque from your beach in the the Bahamas, then quickly communicate that you will implement a feature freeze on the old code, only fix bugs and eventually deprecate it. The rest of them will follow AND they will bring their friends.

What if it happens again?

If it happens again, it’s time to close up shop and go back to waiting on tables. Making a mistake for the first time is naive, I will forgive you. Making it twice is the definition of stupidity. The owner of the company is to blame if this happens and unless they have stupid amounts of money, they cannot and should not recover from making the same mistake twice. However, the reality of big business means that this actually does happen quite a lot but this just means that another smaller more agile company with their head screwed on and all their ducks in a row can disrupt and compete.

Hire good developers, create a functioning and motivated team, engage your users, setup a continuous delivery system to ensure that the software stays healthy and up to date. Then it won’t happen again.

And hey, I could argue that rewriting is actually becoming a natural part of the long term software lifecycle. Technology is moving so quickly that it’s actually not such a bad idea to completely rewrite once every 2 years or so, just so that you don’t fall behind your competitors.

If you do have to rewrite it again, you’ve done it once already so you can improve and optimise the rewrite process. Maybe you didn’t communicate so well with your users last time, maybe you hired the wrong dev’s, used the wrong technology, focused on the wrong features… get meta and iterate on your rewrite strategy!

Seriously now…

Rewriting sounds like a huge task, there are a lot of things to consider: time to market, migration of existing data, parallel running systems or a hard migration date, hiring good devs, keeping the old ones… conversely, refactoring an old system sounds far less risky, definitely less complex and therefore superficially plausible.

But if you are used to working with junior or mid level dev’s and you have never invested in a good software development process, you have no idea how fast a relatively large system can be developed. By employing the best of the best, keeping the process as lean as possible and focussing on satisfying 80% of your users, you can rewrite with 20% of the money/time you originally invested and end up with a product that pulls in more revenue than the original, is cheaper to maintain and is doing what it’s supposed to do — helping your business grow.