Two major code changing techniques, Rewrite vs. Refactor, are available to developers to be able to produce high quality code. On a very basic level, refactoring and rewriting both mean changing an existing structural flow of code. Refactoring however focuses on keeping the core working structure same while improving the way in which the structure is written. Rewriting means to completely get rid of existing structure and start from scratch in creating a structure. Whether the same logic is written again or changed completely depends on the events leading to the rewrite or the team(or a single developer’s) mindset.
Certain situations do require us to be able to determine which one the two techniques should be followed(refactor mostly wins those battles) but it really is dependent on the coders that are working on the project and the situation of their product/project that determines which technique would yield the best results. In fact it is actually mostly the situation that decides for a developer which technique he has to follow to be able to present an end product after all that effort.
1) The time cost factor.
The timeline cost is a major factor that can cause setbacks in a developer’s career. Considering the case of rewrite against refactor, rewrite loses this scenario pretty badly. Since it will automatically put you behind, against your competitors and your own schedule. Refactor still has greater probability to provide success as compared to rewrite. But what happens when the code is so badly written that a rewrite is almost necessary. Well in that case, the developer already knows he has made a blunder in his work(do note that no developer ever sets out to write bad code) and no amount of refactor can fix the problems. The only possible solution left is a rewrite. At this point, the develop is already at bad odds with the client and it’s better to try a rewrite and provide a better(even if late) product to the client.
2) The developers itch
Every developer has that infuriating habit to consider someone else code to be just bad. It’s a trait that most developers share and not something that has a cure. In reality though, the code probably isn’t as bad as the developer believe. Even after following the coding convention standards a developer considers other developer’s code a mess. But it’s not a big problem if the only changes are based on refactors to make the code more comprehensible. However there are some messes that are actually bigger and can cause complications. Such scenario would require rewrite, given the time cost factor is not severely affected.
3) The coders dilemma
The situation that can lead to a developer’s believe for a need to rewrite can be classified into 3 main problems, Structural(architecture) problems, Inefficient code and Hard-to-read/hard-to-maintain code. A combination of any of these can cause a developer to strongly feel about re-writing a code rather than try and refactor through the difficulties. Patience is a key player over here as all these problems CAN be tackled by refactor easily.
The structural changes can be changed massively without actually throwing the core code away. Imagine a 2 page function meant to display a window. Though what make the function 2 page long is actually all the API calls that are not meant to be in there. Regardless it WORKS. It would be a lot easier and less time consuming to try and refactor the changes out of that function instead of just completely removing it(maybe forgetting to add some of the API calls again – new bugs created) and rewriting from scratch.
There is never really a need to rewrite whole thing if code seems inefficient. Efficiency itself does not mean 100% output result. It just means being better than it was previously. Optimize 1% of the code and it can get you 99% better results
Having hard to read code cannot always be bad. It would mean entire code base is following a different yet single pattern. Take a bit of time and figure out that pattern. There would be no need to rewrite the entire thing.
4) Handling bugs/errors
Small changes in code or some unforeseen error at a certain situation are known to arise in the best of products. Developers take a separate portion of time cost for handling the bugs and making structure flow problem free. Refactor is a lot friendly with handling bug problems as existing fixes have a lot less chance to become lost and during code shit, we there are more chances to seeing a bug catch without before it even occurs. Rewrite however has a great probability of promoting bugs. Since in rewrite, the bugs are probably going to be re-introduced that were fixed in previous versions of the original code. Also more time would have to be used to handle any new bugs that can occur due to rewrite.
5) The easier, quicker and cheaper way
After all is said and done, it really is the most cost efficient, time efficient technique that the developer will always choose to change the code. Some scenarios may arise that a product is written in a private language or based on an old buggy custom compiler that just cannot compete with today’s available technology. The described situation may be very rare and occurrence of such an extreme situation may only occur when a product maintenance is neglected for long, in that situation there really wouldn’t be any choice but to rewrite the code base and start anew. The requirement of such circumstances also does dictate how very last resort-ish rewriting is considered as a coding technique.
Most startups would fail just because of the need to have to rewrite the code for their product. In comparison, refactor may just save the developer from having completely failed in his work. Since refactor provides a step by step improvement which keeps the product up-to-date and the client satisfied
