Methodology for Deciding Between Building on Existing Code or Starting New

Question

This is a question about assessing the cost/benefit or ROI of a prospective project.

I'm working in 6-8 old years software project. It has a lot of issues and also failures plus some failed people on its way. Right now after raising the project (software application) from the dead, when the new requirement comes, the developers are looking in the code (not in the working features in terms of usage) the corresponding code. There are ideas of creating, rewriting the project from the beginning. I wonder if there is a sense from your point of view to look in the old code something that corresponds the new requirement for the current application? Because if it is different, then the developers are getting back to the requester, describing what they found in the code, and once again discuss requirement.

In one side it fosters requirements engineering and requirements gathering process, on the other hand it may be waste or unnecessary extension of the time. Because it may be better and faster start from scratch with the new code for the new feature. And especially if the new system or rewriting the system can be the case.

While there may be opinions on this subject, it would be helpful to find a methodology so I could recommend whether the stakeholders are better off continuing to invest in the old code or build from scratch?

Answer 1

Your question is pretty complex and does not lend itself to a clear answer. Given the abiguity of issues your question raises, you will find most StackoverFlow participants inclined to discount it as opinion-based. Nevertheless the question is a real one that IMHO deserves a reply.

The legacy code is familiar to the to the programmers that wrote it, so they will naturally look there first to address new requirements. The requester likely does not care how the task is accomplished, but they will lean toward fixing the existing code. Unless they are aware of how code is written and works, they will have the view that repair would always be quicker and cheaper than replacement. Often that is the case, depending on the new requirements.

However the accretion of patches over time can generate technical debt that can jeopardize not only the application's enhancement but also undermine its performance. See work by Martin Fowler, Ward Cunniham, and Steve Mconnell, in particular the latter's Managing Technical Debt Webinar.

Moreover, the advent of new languages and frameworks can lead to more effective, secure, and/or efficient solutions. Moving to these new approaches may be seen as a welcome challenge or terrible idea depending on the developer's personality. I would identify a couple target application architectures and draw up the advantages, disadvantages, and interesting points (that dont fall into either category).

The Mythical Man-Month: Essays on Software Engineering by Fred Brooks is a classic book on software engineering that gives a high level perspective of these issues. Look for "the second system effect."

Kindly search https://stackoverflow.com/ and https://softwareengineering.stackexchange.com/ for relevant entries.