Project managers are faced with the dilemma of repairing code or do coding from scratch when a project has had its runtime before. They have always struggled with making the developers repair someone else’s code. In some cases, the developers don’t know who wrote that old code and where to look exactly to fix it. It’s like finding a needle in the haystack. They try to avoid that re-work and prefer working from scratch.
So, the project managers are left with the choice to re-work the whole thing again. But, that’s an expensive deal plus time-consuming. Assuming that there’s a tight deadline and budget in the project, a complete overhaul doesn’t sound like a legit choice.
One cannot paint all the scenarios with the same brush. Sometimes, rewriting seems more promising than repairing. It is rather profitable to spend money and time in working from scratch than to keep digging the barren land. Both have their pros and cons based on the case scenarios.
Not favored by many, but fixing an old bad code does have its pros. Whether dealing with legacy code or faulty code, if the website or the application is still functional and parts of it need re-touching, it can be repaired.
Repairing the code without fully understanding it is a mistake too expensive to commit. Know the code before touching it. To understand the code the developers must have the below information, to begin with.
Make a list of things that need to be changed. If the list shared more than 60% -70% of the work, repairing would be troublesome and equally time-consuming as rewriting fresh code. The list will also help you see exactly how many hours are needed. Start by segmenting the big chunk of code functionality-wise and page-wise. Each list item will have a description to know why it is needed to be repaired.
Repairing the code is better done slow. It’s like rewiring the entire system. One wrong connection and you have to re-do everything because issues in the patch work might cause new errors. That will do more harm than good. So, take each step carefully. It’s like walking in the mine-field.
Cosmetic cleanup or refactoring is another way to take things forward. First, you make it understandable in your own standard coding practice, and then you apply changes. It’s a safe bet. It’s like translating Hebrew into English first and then trying to understand its meaning.
Look for the coding portion that is causing the maximum issues. This might fix many other minor issues. It saves time and money. Hit two birds (not literally) with one stone.
If initiated strategically, any developer can work on an old developer’s code
Coding from scratch equals working on a totally new project. However, the approach to coding from scratch is different from repairing the code.
Make yourself clear on the following questions before deciding to code from scratch
A good way to start developing from scratch is to have a web development project brief at hand that will serve as a guiding light throughout the journey.
Having too many choices is stressful. Over-analyzing delays decision-making and puts you in a situation worse than where you were in the beginning. Make a list of pros and cons for each choice – repairing and coding from scratch. And, of course, there will be a few points on both sides which you will agree with and a few with which you will disagree. You just have to accept that considering your situation.
Understand that some products are never ready or fully complete. A website or app like Facebook has endless potentials. It’s never complete.
As two very wise men have said
"It is Better to be Live than Perfect" – Sajeel Qureshi
"Perfection is the Enemy of Progress" – Mark Cuban
These two quotes are so true and all product owners need to embed these in their product manufacturing process. It is good that you want a close to perfect product for your audience, but if you keep on criticizing your own product from your perspective, your product will never take off from the ground. The ideal way is to launch it, let the users use it for a while, let the users give you feedback, and let the product grow or improve at its own pace.