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.
Repairing an Old Code
Get to know the old bad code
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.
- What are the end functionalities the client wants from app/website?
- Is it better to go to a newer version now or can it survive the a few more years?
- How many resources would it take to repair the current code?
- Would the cosmetic clean-up do the job or an in-depth rectification is required?
- How vast is the impact of the current bad code? Is it resonating throughout the application or website?
- Is the code not working because it is bad or it is just outdated?
List out the Changes needed in the Old Code
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.
Go Slow – Go Strategically
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
How to Code a Website from Scratch
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
- Is the old code causing the drag to the product? For how long this old bad code will survive in this fast-changing tech world?
- Is the code meeting the new requirements of the target audience?
- How beneficial it is going to be for the app/website if the code is written from scratch?
- Time and budget for the complete code-writing from scratch versus the time and budget for the repair?
- Should we repair the code and let it have its run until we have the budget and time to rewrite the whole thing?
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.
Don’t Get Analysis Paralysis
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.
- If spending a little more on coding from scratch can save your product from sinking, don’t think much about the loss you’ve had with the previous code. The final launching of the app/website will be worth the investment.
- If there isn’t much cash flow to support the app/website, then repairing code, and introducing the updates one by one in the future as your budget improves are wise options. Your product won’t have a quick run through the market, but it will flow steadily.
- If you have already spent the time repairing code and nothing good has come out, it is better to code from scratch.
- If the code can support the new tech and can have a good run for the next few years but isn’t working because it is just coded badly, spend time on repairing it first. The fire is in there in the code, you just need to light it.
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.
