PMs guide to tricky questions: To rewrite, or not to rewrite?

During the last several months our team came across 3 projects with the same issue – customers had the “almost done” project (usually customers state smth like “85%” or “95% done”) but they could not launch it, because the bug fixing process was endless or the “last crucial” feature was almost impossible to implement. Almost all of them were startups. We performed code review for them to be able to answer if we can handle it. From inside the products looked very similar. I think I even could tell all their development history by looking at these layers of code, covering each other like patches in a crazy quilt. We usually ended up with these clients arguing about one question – “Rewrite or do not rewrite all of that”. So I decided to write this post about the BIG rewriting.

How it all starts

Option 1

Startup team starts in very enthusiastic way. May be they don’t have all the skills in the team, but they are going to learn. They produce a lot of exploratory code fast to be able to create first “proof of concept”. The first version is the success, users like it. Yes, the design is not perfect and there some bugs. But there is no time to stop and think it over – everything changes so fast, they need to keep up with the market – product management requires new features to be released. Team is concerned about the continuous delivery and fast time to market, they even hired all those agile coaches to improve the process. And one day development team finds themselves in the nightmare – 100% of the time they just try to keep up and support the code, where one bug was fixed – thousands new appear. Now they have to pay for all of that quick and dirty coding they had.

Option 2

You work in the outsourcing company. One day a very excited sales manager enter your room and announces “We just got the contract with X! They are transferring their project from A to our company. It’s a huge project, they worked on it for several years already.”

So what happens next? The team lead comes to the manager and says – “We performed the code review…And we think we can’t work with this code any more. We need to rewrite it”.  But your customers/product managers are requiring new features to be implemented asap! And if you think that the idea that comes immediately to your mind – just firing this developer and hire a new one – is a good one, you should know that it won’t work. When a new one comes on his place he will be even more for rewriting everything (have you ever seen a developer giving a good feedback about the other developer’s code?).

I would like you to be prepared for this situation, so here are some of the pros team lead can tell you in favor of “rewriting it from scratch”:

What can be a good reason

The code is useless

When the code can become useless:

• It is so badly written, full of bugs, not relevant, represents all the anti patterns. You should be careful with this argument, as developers usually want to present the situation worse as it is – no one likes to deal with the badly written code. So I am talking about the extreme situation – when it is really, really bad.
• Technology is not supported more, legal licensing issues. Usually such things are not unexpected.
• The changes that we are required to be implemented are not possible with the existing code. For example, if the code you have now was the pilot version which was not created to be a fully functional version.

Big changes

When you make such a huge pivot that the architecture should be changed dramatically. Especially if the problem you are going to solve is too complex for the original language or technology.

You can’t find the code

It’s  really funny and you could say that it is not possible. I was thinking the same way! But I had such a problem several years ago.

Our customer wanted to add new features to the application which we published a year ago. In our repository we had the version 1.5 and we could not even compile it, but the app on App Store was 2.1. Seems that we missed something… After spending some time investigating I found out that guys were even aware of the code missing – the developer who was working on this project left this company some time ago and…took the last version of the code with him on his laptop, not pushing it to repository. Don’t ask me, how it can be possible, I was surprised too. So we had to rewrite it at our own costs.

Bad reasons

Code is ugly. My eyes are bleeding.

Developers say that all the time. The problem here is that it is much more difficult to work with the “old” code than to create the new one. And even your own code becomes “old” very quickly – when you leave your place to have a cup of  coffee and get back you find out that the code you wrote 15 min ago became an “old” one and you have to spent some time on studying it before you can continue working.

We are all thinking in a different manner and the code we create is the reflection of our thinking process. Yes, we standardized everything and developed a lot of patterns and ready made solutions, p. But human brains still find the place for art in this land of rules and standards. That is why it is so difficult

It was not created according to the way I think it should be created/ They haven’t used this pattern/technology/etc.

Developers usually know the right way how to do everything in life) The same as you, managers.

It is very difficult to understand how it works

(really he means: “We don’t want to figure out how it works”).

“It depends” reasons

The nightmare situation

Nobody can figure out how it works, no documentation about how it should work
Especially if you have a new team – it can look like a disaster. We have 2 options here: 1) spend time on trying to study the code base, recreate the requirements, implement proper testing and understand if the code is working according to requirements. There is a risk finding that it is far from working according to the requirements or even just working. But there is a chance that it is not so bad and it can be supported and improved – refactored step by step.
2) through it away, recreate the requirement and write a new version from scratch.

The most important thing for the manager to know is that there is no cheap way out of this situations. With ways are expensive. But if you have this product already published and functioning – 1) provides you a chance not to loose your market.

Things to remember

• Be very careful when you create some “pilot” or “proof of concept”. You know, that you create some “demo” very quickly and not thinking that someone would re-use this code. Because it is just a pilot, yes? Management is happy with getting the demo in just a several weeks and shows it to the potential customers. That is when you get in a trouble. They come back and ask you to add new features! So the product can be published! No one wants to listen about the fact that you need to “rewrite it in a proper way”.
  Remember, business people don’t care about what is inside of the product (until it is not causing the issues, I think). If they see the screens with buttons – they think it is ready to be sold. And they sell it. It is their instinct! So set the expectations properly!
• Paying you technical debt. Your can’t be ideal. You’ll have to make changes all the time. So you have to balance all the time between the speed of adding new fictional and paying off for all the cut corners in the past.