My first article in my own Blog, which was followed Jeff Atwood’s advice: How to Write Without Writing.
Today I asked a question in Stack Exchange. In stack exchange, there have some point of views. Someone think we should rewrite it and someone think refactoring is the best choice because rewriting is the last resort.
This question came from a real situation in our project. The module began with a graceful and concise aspect just as the beginning of the fairytale:” Once upon a time, there was a beautiful princess…”. An experienced programmer wrote the original code which was readable, robust and neat. It worked well in systems and gained reputation for the programmer.
With more and more features added to the systems, the code base got worse over time. But it was the same aspect as former code in the surface and one day the programmer was promoted to team leader. A junior programmer just graduated from university took over the module and coded with great care. Unfortunately, he or she didn’t know all the fundamental decisions and ideas behind the architecture. The team leader was busy in his or her new management affairs and ignored the transition of knowledge. When features flooded into the systems, the new comer complained to the team lead and asked for help. Then a new member of the team was added to maintain the module who was still not familiar with the module. More people – less communication. Less communication – bad decisions. Two years later, the module became the hidden bomb in the systems.
How to deal with the problem? The question was raised by project manager eventually and there have just two choices: rewrite or refactoring.
Michael Dubakov suggested that,
Though refactoring and rewrite might lead to cleaner code however, both the techniques bring chaos to the existing system. Refactoring is an incremental activity hence it touches some portion of the system at a time. This creates chaos at local levels and might be easy to contain. Rewrite on the other hand is a more invasive change and results in a bigger chaos in the system. Due to the wider impact, the stabilization period of a rewrite is much longer than that of refactoring.
As Joel on Software suggested,
It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.
Return to the living example, experts mentioned the risks and chaos brought by the rewrite and refactor, so it is difficult for the team members to make up their mind to start. Netscape, Friendster, Myspace…, the long list of the companies which made the worst mistake had the same point: they rewrite the code of their mainstream products.
According to general common sense, this horrible news may hold up the pace of the team members. But with repeated discussions and meetings, the final decision is rewriting the module with some special policy.
The module has some characteristics which were different from Netscape, Friendster and Myspace. The module has twenty thousand code lines, and the prediction of the code line after rewriting is the same. The scale of this module is far more less than the gaint products, so rewriting the whole module is easier to under control. Another approach is dividing the team to two parts, one team maintain the old code, and the other team rewrite the module. When the rewriting complete and is verified to reach the release standard, the new module will replace the old one. Before this, these two modules run in parallel.