Fix or rebuild? How to decide what to do with a failing software project

When a software project has gone wrong, two loud voices tend to appear. One says the code is nearly there and just needs another push. The other says the whole thing is unsalvageable and should be started again. Both are usually guessing, and both have a reason to believe what they believe — the first because they built it, the second because a rebuild is easier to sell than a repair.

The decision deserves better than either. Here is how to make it on evidence.

First, secure what you have

Before anyone assesses anything, make sure you can actually reach it. This matters most when the relationship with the original developer is strained or ending.

• The code: administrator access to the repository, with its full history, not a zip file.
• The running system: the hosting account, the database and its backups, in your organisation’s name.
• Everything around it: the domain, DNS, email sending, app store accounts, and the keys for every third-party service it uses.

If any of these sit in someone else’s name, fix that first. Our guide on owning your source code has the full checklist.

Establish what was meant to be built

You cannot judge how far a project is from finished without agreeing what finished means. Reconstruct the intended scope from whatever exists: the contract, the specification if there was one, the tickets, the email threads where features were promised.

This step often produces the most useful finding of the whole exercise. Many “failing” projects are not badly built — they were never clearly specified, so the developer built one thing and the client expected another. That is a requirements failure, and rebuilding with a new team will repeat it unless the scope is written down this time.

Assess what actually exists

With the intended scope written down, look at the system against it. Four questions do most of the work:

1. Does it run? Can someone outside the original team build it and deploy it from the repository, following instructions that exist?
2. Is it tested? Are there automated tests, and do they pass? Untested code is not necessarily bad, but it is much more expensive to change safely.
3. Is the data model sound? Do the database structures reflect how the business actually works — its entities, their relationships, their rules?
4. Can a new team work in it? Is it organised so that a competent developer can find things, change one part without breaking another, and understand why it was built the way it was?

The data model decides more than the code does

If there is one thing to look at hardest, it is the data model. Untidy code sitting on a sound data model can usually be repaired a piece at a time. Clean code sitting on a data model that misunderstands the business cannot — every feature built on it inherits the misunderstanding, and fixing it means touching everything.

This is also where an analyst earns their keep in a rescue: judging whether the model is right requires understanding the business, not just reading the code.

There are four options, not two

Framing the decision as fix versus rebuild hides the options that are often best:

• Stabilise and finish. Fix what blocks a release, then complete the remaining scope against a re-agreed, written specification. Right when the foundations are sound.
• Cut to a smaller first release. Ship the part that works and delivers value, and defer the rest. Often the fastest way to stop the losses and restore confidence.
• Rebuild one part. Keep what is sound and replace the component that is not — commonly the data layer or one badly built integration.
• Stop. Sometimes the honest answer is that the problem should be solved by buying a product, or not solved in software at all. Stopping is cheaper than finishing the wrong thing.

Each option needs a cost and a risk next to it, so the comparison is real rather than rhetorical.

The traps on each side

The rebuild trap. A rebuild almost always looks cheaper at the start than it turns out to be. The old system, however flawed, contains decisions and edge cases that nobody wrote down — and the new one has to rediscover them. A rebuild without a proper specification is a second attempt at the same mistake.

The fix trap. Money already spent makes it hard to admit that more spending will not help. If the same “two more weeks” has been promised for months, more time on the same footing is unlikely to change the result.

Who should make the call

The team that built the system has an interest in saying it can be fixed. A team that wants the work has an interest in saying it needs rebuilding. The decision is best informed by an assessment from someone who is paid the same either way, delivered as a written report you can take to your board, your current vendor or anyone else.

That is how we run project rescue: a fixed-fee assessment first, with the recommendation and the reasoning shown, and the choice of what happens next left with you.