What I mean when I say:
Rewriting: Taking the requirements of a given system and coding them in a different language, architecture or paradigm.
Refactoring: Bending code by restructuring it to fit a new paradigm for the sake of maintainability, testability and extensability
Early in my career, every legacy system I came across seemed to be prime for rewriting. Surely all my new tools could produce a better barn than the barn we currently had. Surely it would make a barn that never needed to be refactored or rewritten. I was allowed to chase that road too many times and at too great a cost to consider the constant clamor for "Rewrite it" to be my default.
Here is why.
Lie #1: Rewriting makes integrating new features easier. You can build them in from the ground up.
Answer: If the software has not suffered organic growth, rewriting will end up in the same place as a refactor. Even if the code ends up following a different paradigm, it still has to meet the original requirements.
Lie #2: Refactoring is hard. It is hard enough to make it not worth it.
Answer: It can be, but it can also reveal if a rewrite is actually needed. It can expose systemic problems that you can't see otherwise.
Lie #3: Newer technology makes code cleaner and easier to maintain.
Answer: Javascript, C#, Java, Python, Ruby, and Go all suffer from the same problem; they are languages. They all have encumbrances that try and hide the hard parts of computers away from the poets and wizards writing code. Those encumbrances are prone to obsolescence. I wrote quite a bit of C# code for .Net 2 & 3. None of that code would run today. Windows has changed. I wrote a Javascript booking engine for a travel site in 2001. It would not even render today. I could easily take that same code, however, and update it to run in any of the latest stacks. The answer of rewriting versus refactoring can be driven home on this point. I already paid the price for those features once. Why would I pay it again?
The idea of software maintenance should expand beyond bug fixes or incremental feature adds. The roads we walk to a future state are shifting sands. We have to keep on top of that technology and build that price into our code.
Lie #4: It is cheaper to rewrite it.
Answer: Maybe. If the stack is based on an ancient technology that cannot be modernized and the price per developer is more than the initial cost of the product, it might be cheaper. If it isn't boxed into a dead vendor or dead language, this argument becomes much more false.
In general, unless the product name is the only thing being reused, I evaluate this based on the number of functional features in the code base vs what is being asked for. If I already have the code, why would I pay for a rewrite?
Top comments (0)