Rewrite the whole thing

I want to talk about the great Software Development paradigm that has been around for many years: The “rewrite the whole thing”. Start by writing a software system. When it’s ready, put it in the market. Spend 1-2 years improving it, fixing bugs. Start again. We’ve seen it with Microsoft, for example. Remember Windows 3.11, 95, 98, …?

The software system reached a stable state and to a considerable complexity. Decisions thought to the best at the time, were not after all and are limiting future developments. Some years of bug fixing helped entangle it even more. It became a legacy system.

Legacy systems

Legacy system is often said to be a system without test coverage and no one understands. That might be true, to some extent. Is a system with good test coverage not a legacy system? Show me a good test, I’ll show you a hundred bad tests. If someone understands the system, it’s not a legacy system? Ever heard about “Oracle” developers?

Legacy conditions refer to a system’s difficulty (or inability) to be maintained, supported or improved.” [1]. Legacy systems are hard maintain and to implement new features on. The simple fixes are dangerous, time consuming and can have unforeseen consequences. Changing it is always a last resort. Systems loose their commercial value, until it becomes obsolete [6].

No one wants to work in a Legacy System. Productivity is almost none. It is painful. The technology stack is so ancient, developers feel stuck. Nothing new is done, just fire fighting and bug fixing. Staff turnover is high.

When the company looses competitive edge and market share, Management realizes something is wrong. It is time to change!

The easy way out

Rewrite the whole system is the simplest way of dealing with a legacy system. The old system is there, no one changes it, nothing gets broken. The new system, a greenfield project, is the dream of every developer. Everyone is happy. Development is fast. Finally “bleeding-edge technologies” can be used. There is hope for the company’s Software Development.

“This time we’ll get it right” syndrome

I’ve heard several times from senior management the words “rewrite the whole thing”. Beliefs “this time we’ll get it right” can based, not exclusively, on:

  • “This time we’ll get it right, we’ve learned from our mistakes” – Unless something radical changes in company’s culture and people’s behavior, it will happen again. Not the same mistakes, but new ones.
  • “We are going to do Agile” – Years rewriting a whole system, unplug the old one and plug the new one is Agile? “We are going to use SCRUM”
  • “We’ll take the time to do it right” – Forget about competition and clients that pay our salaries. Let’s freeze software development for a couples of years.

Don’t underestimate legacy systems

Legacy systems provide incoming to the business and have been doing it for years. They do it for a reason: it works and has value! There is a lot of knowledge in it. Significant time was spent on refining it. People that wrote it were not dumb. They did the best they could and knew.

On a company I’ve worked for, there was a big legacy system more than 20 years old. It was common to find code written back in the 90’s-00’s. Every new Software Manager tried to get ride of it. Tried rewriting the whole thing. After a considerable time on such mammoth task, managers realized it was nearly impossible or took much longer than initially planned. No manager lasted more than 2 years on the job.

The same legacy system is still there. It endured developers, managers and money invested. The Development team learned to fear it and respect it. It was safer to write layers to abstraction on top of it, sweeping it under the rug [2].

The hard way out

Never liked the expression “If is not broken, don’t fix it”, but engineering is about finding the middle term. Instead of slaying the dragon, why not tame the dragon? Take the time to analyse the big ball of mud [2]. Study it. Make minor improvement so it is easier to tackle it a small bit at a time. Rewrite small pieces, when needed, without bring the whole system down [3] or freezing new developments.

Seems obvious. Right? So why do I keep hearing “rewrite the whole thing” over and over again? It easier said than done. It takes time and huge effort to tame a legacy system and advantages are not easily perceptible. It takes courage!

The Management opposition

Software development is about producing, making something. The senior management needs to know what was done last week and what is going to be done next week. Unless they see very persuasive numbers, no one will be allowed to produce “nothing” for an undetermined amount time.

It is easier to see the shortcoming results from rewriting the whole system. Development is so fast in new projects and nearly imperceptible when dealing with legacy systems.

The developer opposition

Working in a legacy system or greenfield project? I will always pick the greenfield project. Once I worked 6 months upgrading the technology stack from a legacy system. I would get out of one rabbit hole just to get inside another one. It is something I would not like to do again.

Some humble pie

We make bad decisions all the time. We are not able to guess the best solution. It requires proof of concept, really world usage, user input and most important time. To make matters worst, what is valid today, might not be valid tomorrow. Can the whole thing be rewritten on time to not be outdated? Won’t today’s greenfield project become tomorrow’s legacy system?

If the company eventually embarks in this Kamikaze approach, some cheques along the way and no ROI, Management will start thinking it was a mistake [5]. After considerable time, effort and money spent. Management will call everything off. Every effort will be thrown away or worst, left behind to augment the big ball of mud. Development team will be held responsible, rightfully. It is very hard, if impossible, to gain trust again.

Conclusion

This is not about why a system became a legacy system or how we can prevent it from becoming a legacy system. It is about the problem with “rewriting the whole thing”, when a system reaches such point.

On today’s competitive and fast changing world, Big Bang releases are a risky approach [6] [7]. Rewriting a whole system is too costly and takes years. Years with no return of investment. Years to reach the market. Years making it outdated. It is a huge competitive disadvantage [4]. It should be use as last resort, not as first approach.

As Software developers, we should know the disadvantages and problems of this approach. Make sure everyone is aware of it, before embarking on it. We should fight the temptation and be the first ones to say NO. It is our job, as developers, to look out for the company’s best interest. It is our job, as developers, to look out for the Software Development reputation.

References

[1] https://www.techopedia.com/definition/635/legacy-system

[2] http://www.laputan.org/mud/

[3] https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/

[4] http://www.techradar.com/news/software/operating-systems/microsoft-confirms-there-will-be-no-windows-11-1293309

[5] https://vibratingmelon.com/2011/06/10/why-you-should-almost-never-rewrite-code-a-graphical-guide/

[6] https://steveblank.com/2011/01/25/startup-suicide-%E2%80%93-rewriting-the-code/

[7] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s