And you can make another fundamental mistake after reading Netscape story
Here is famous Joel’s thoughts on Netscape Story.
Half or more of tech world has something to learn and follow from Joel.
After the impressive comments from Authority like Joel, others build their opinion about code rewrite, almost in fixated manner without considering how different situation they are in compared to Mozilla.
If you are in coding for some time and do not know Netscape’s rewrite case… this post will be irrelevant to you.
Netscape made mistake at most crucial time to waste 3 years in browser rewrite giving a winning chance to IE to come from nowhere and catch to become leader.
Netscape code was working. It became better and better through numerous workarounds and fixes written to survive the various Operating Systems bugs. This was built over a long period. It was scattered everywhere in the code. It was the real IP of the Netscape code that it can work in spite of so many severe issues in memory management, APIs functioning etc the Operating Systems had.
Possibly you could have written a very good HTML renderer browser but that would not work well on Operating System that runs it. So you have to fix for others bugs. And this is most difficult thing that a coder would ever want to do. You don't know what to fix without someone unhappy and reporting it.
Think of this as through an analogy.
The HTML coder your company has, wrote a correct XHTML code. But it does not works well on various versions of the browser. The HTML coder did not violate any of the HTML or CSS standards. Now what he has to do? Case by case for specific browser versions, create CSS, HTML and JavaScript that would work correctly.
So you got the point here. The HTML coder has to patch for issues in browsers to make his web page render correctly.
Let’s go back to Netscape case.
Was Netscape browser rewrite and waiting it to release to public for 3 long years was wrong? Simple Code Refactoring activity could have fixed everything. True.
Why was that required?
Poorest maintainability of the existing code due to bad logical arrangement of code.
Lots of boiler plates damaged logical integrity by damaging earlier simple structure, introduced redundant and wrong place fixes.
Now the situation is, it takes time to change anything because system lost maintainability charm.
As it is too difficult to understand for someone to make any change for better.
Fixing here breaks at other unexpected places.
Many unexpected ways system was maintaining its working.
But the reality was,
Netscape Browser was working well in spite of all OS issues.
Others would certainly need time to catch Netscape. It was working irrespective of thousands of bugs in the systems on which it runs. And Netscape could run on such diverse systems by fixing all such many issues.
The biggest argument made against was, code was not at all maintainable or understandable easily because the state it was in.
Because of bad code, for Netscape, eventually features took really too long to build because it is so difficult to add or improve things for developers. Even any new change breaks the system at many unexpected places. Nobody had neat idea what is in the code.
Netscape was wrong in its approach to fix it.
When you meet a monolith code, you are in mess. That’s why good architecture and design helps by separation of concerns to make it independent of developer’s maturity in code writing.
For Netscape, a simple refactoring by rearrangement of code could have been done easily. Certainly taking less time compared to 3 years, and without losing the IP it accumulated.
But they rewrote it from scratch. Taking 3 years gap. And the new version was massively buggy with the earlier IP missing.
And you can make another fundamental mistake after reading Netscape story.
When you are in Netscape situation, do refactoring. But are you in the same situation?
1) Better technology is not reason to rewrite. Bad code is not reason to rewrite.
2) Another fancy framework is not reason for rewrite. Do refactoring.
3) Trading for business/operational value against the cost of rewrite. You may not need 3 years to rewrite. In some cases it may be just very less time. (Once I met with email module written badly in one of the product. Every week there was situation to look down and feel insulted when emails goof up with customers. We continued for 6 months like that with choice of to fix than rewrite. When we rewrote the module it took just 1 week for a senior developer.)
4) Paradigms shift in technology every decade. From website to mobile ready website then Mobile App then Platform Integrated e.g. Facebook specific App that open inside FB Mobile App as FB Website then ...
Because you want to meet more customers and they have moved to some different format, you may want to rewrite
5) Security can be a reason for rewrite. Scalability can be a reason for rewrite, because it can change the recipe completely.
6) To fix earlier wrong choice of framework or components or technology stack or wrong design... refactoring will not work alone. Instead consider rewriting specific identified parts of the system.
In last 14 years I met with at least 9 massive rewrites and flipped the business situation to great advantage. Some rewrite took 10 weeks to rebuild a 15 months teamwork while some rewrites took more than 3 years. And in all cases all rewrite cases had same symptom of Netscape earlier but different reason actually. Some of those rewrites were in approval with business people. Those rewrites made business come out of severe risks time to time.
A half dozen more rewrites were simply refused and still suffer same maintainability curse in past 6 or more years. And they did so after knowing Netscape story. Bookish something.
My last mega rewrite was changing an entire system which was coded and value added for 13 years on everyday basis. It took 2 years to rewrite for team of 12 coders, using my another work of 2 years in AI and Java based system developed with another team of 3 coders, as a base line.
Result was complete transformation. Earlier employees were resigning due to too much workload. Company was profitable but was in risk as most old and loyal employees wanting to leave as it badly imbalanced work and home. After new system was in place, employees were happy. Same company could now take up the new opportunities which made it earn highest revenue growth since its existence.
Rewrite is last choice because it is very intense and riskful. Knowing when to use it is critically important.
My word of caution for you:
Business people do not like rewrite because it is throwing away value created. They probably want to kill you for 2 things… 1) there are severe problems open for long and you are not fixing it yet and 2) the plan you propose is “rewrite” to fix most problems.
When business people start influencing technical people often technically wrong decisions are pushed.
One of the killer decision is “To Rewrite Or Not”.
When you are not an expert in the field, and in complete power to influence what decision the experts should take, you often force your beliefs than letting correct decision be made by experts.
Corporate Psychologist often know how to instate balance through designing decision and power structure. Some good managements like Google, FB implement it in better way.
Most code gets rewrite for many reasons. A small portion of code is most long living without any change. Complete rewrite can be a bad idea, but it depends on if you are in a specific situation like Mozilla.
