It is a very common, that a programmer feels the urge to rewrite some piece of code. Admit it. You feel that urge to. To redo some pile of shit supposed to some basic task. It has many bugs and thousands lines of code. It does what it does, barely. The only logical choice seems to be rewriting it. Reduce number of lines of code. Reduce some complexity while doing it.
Is this a right thing to do? Many would argue that it is. But I would strongly argue that it may not be the best thing to do. And I have a very good reason for it. It is not best thing to do because your decision to rewrite probably does not depend on logic. You just feel like it. Because you fear the complexity of the code. It is very hard to read the code that some other person wrote. So it is only natural that you feel an urge to rewrite it.
Why Need A Rewrite?
Reading code is harder than writing it
You have given task to maintain some legacy code. It is written badly, it is complex and it consists of thousands lines of code. The code expanded its original intent long ago. Many code pieces pushed into it. And there is a bug you have to fix. So you have to have a very good grasp of the existing code in general. What parts affect each other. What are the dependencies. Understand design decisions made. And try not to break things while modifying code. If you are lucky there may be unit tests. So you will feel more secure making changes.
It Is Written Badly
The code base may seem to you a collection of best bad practices for the language it was written. There are no coding conventions followed, variable naming does not fit your taste. It even does not use, the new language features. Lame isn’t it?
Why Rewriting Might Be a Bad Idea
You have to think twice before rewriting and make sure that it is not a decision based on your feelings. Because there is no guarantee that, the new code you will write will be free of the short comings detailed above. You’ll probably want a rewrite, because it is better if the complexity is created by you not some other one. You want to know reasons of all workarounds, you want to know why a function is implemented the way it is implemented. So you can feel secure about the code. Because it is your pile of shit, not others.
And you have to understand that, in future, even your newly written shiny code, may become more complex than the original legacy code. That is because, requirement will constantly change. So do your new code. You will never be sure of requirements at a given point in time. So there is no possibility that your code will be friendly to future changes. So you have to trade some quality away to implement some new features, or some small changes. In time, your code will probably become more monstrous than the old code.
So be merciful when judging the people who wrote the old code. You do not know under what circumstances they implemented that solutions or how their requirements changed over time. It is maybe your fear of complexity that makes older code seems so shitty.
What To Do
Up to now, you may have thinking that I completely disagree with any kind of rewrite. By all means, I do not. I am just skeptic about the feeling of rewrite. I do believe that all code needs a rewrite. But I just do not like the idea of complete trashing of old code and starting over. It is dangerous. It may even cost you the company or product.
Rewriting should always start with old code. You first have to understand its general structure. Try writing some unit tests if there is none. Try splitting files so there would be a separation of concerns. Identify individual features. Pay some technical dept. Try to quarantine the code as much as possible. And only after that, you start to rewrite. Part by part. So that you won’t loose the maturity of older code. You will always have a working product. You will better understand the code. And will be more eager to improve it. You will be more agile!
So go rewrite some code. One piece at a time.
PS: Here is a wonderful article on how detrimental can a complete rewrite be : Things You Should Never Do, Part I.
