Why do Developers rewrite code?
Have you ever encountered this question, or as a developer has anyone have ever asked you this question. Why do developers rewrite code? Well happened to me last night. A good friend of mine gave me a call and asked me the same question and I was like wait…. What??? Why the hell are you asking me this question. To give you a little context, he is a product owner and they expanded their team few months ago. Now, there is a huge demand from his dev team to rewrite the code again preferably in a different language. When asked, all they gave is a big word which we as a dev like to flaunt, Yes you guessed it right, it is…. “Technical Debt”. We had a good discussion about the whole process and that is the inspiration for this article.
Coming back to the original question, Why do developers rewrite code?, I believe the number one reason was given to us by Joel Spolsky — Founder of Stack Overflow and Trello, and that is:-
“It’s harder to read code than to write it.”
He wrote an article 20 years ago, yes you read it right. The article was about the big rewrite done by a company at that time called Netscape, which led to their downfall. He explained and made a good argument how the rewrite drove them out of business as they were trying to rewrite a working code while their competitors were gaining a market share. He gave more examples to support the same. I would like to mention few lines from the same article here which defines our urge to do the rewrite:-
“We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.” — Joel Spolsky
I believe this is right and might have happened to me in some cases. But as a developer I know this can be one of the major reason but not the only one which drives us to rewrite everything. One is already mentioned above that is Technical Debt. Now, to understand technical debt, lets look at the definition in Wikipedia:
“Technical debt (also known as design debt or code debt, but can be also related to other technical endeavours) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” — Wikipedia
Sometimes, because of the speed of the product delivery we cut some corners and add some patches to the code which are basically quick hacks to get the product out of the door. Like any debt, the Technical Debt keeps up accumulating and in the end we have to file the bankruptcy and start from the scratch i.e rewrite. Can we manage this? Maybe yes, if we allow ourselves to create things with proper solution in the first place. Sometimes, this is not possible but like any debt we can manage this as well, by refactoring the code or retiring the pieces of it which are no longer serving their purpose.
This is a kind of a tussle between product owners or management of the product and they don’t know what to say when someone from their dev team comes up and say, “We need to write it from scratch”. In their eyes, standing codebase is an asset and you don’t retire something which is already giving you a revenue. But to rewrite something, we should first understand what was there in the first place. If we don’t understand the initial codebase which was battle tested and evolved after receiving user feedback, are we in the right position to rewrite the stuff. This brings us in the same problem where we are saying “It’s Harder to read code Than to Write it”.
Following are some points which I believe should not be the reason to rewrite code:
- It’s Fun!!!
- I want to learn or use a new technology in it.
- This is not my comfort zone, so let’s rewrite it to something I know.
- Rewriting just because it is a mess is a losing strategy, you will find examples of this in Joel’s Article.
- If you can refactor don’t do rewrite.
Then, when should we rewrite the stuff, I guess the following pointers might help:
- When the technology used is no longer available.
- When the product vision is no longer aligned with the current codebase, we should retire the pieces in a planned manner.
- When Technical Debt is slowing you down and it is not longer possible to speed up the things with current situations. But keep in mind to retire stuff in planned manner (Microservices).
- When better solution is available and we can rip off some bandages from our code base to make it healthy.
In the end I am going to leave you with a quote by Bjarne Stroustrup
“Legacy code” often differs from its suggested alternative by actually working and scaling. — Bjarne Stroustrup
References:
Originally published at https://simranjeetsingh.in.
