Can another developer finish your software project?

It is usually asked quietly, near the end of a conversation, as though it might be a silly question. Can somebody else pick this up, or have we lost it?

The short answer is yes, nearly always. We do it most weeks. The longer answer is worth having, because what makes a takeover easy or hard is rarely what people expect, and knowing the difference tells you whether the quote you have been given is reasonable.

The question behind the question#

Almost nobody asking this is really asking whether it is technically possible. They are asking three things at once.

Is the money I have already spent wasted? Am I about to be told to start again? And is the person telling me that going to be telling me the truth, or telling me what suits them?

Those are fair questions and we will take them in order.

Reading somebody else's code is normal work#

There is a belief, and it is common enough that it is worth naming, that code is personal in a way that makes it unreadable by anybody else. That a system is somehow keyed to the person who wrote it.

It is not. Software is written in ordinary languages with ordinary structures, and a competent developer can read another one's work in the same way a competent accountant can read another accountant's books. It is not always pleasant, and it is slower than writing new code, but it is normal professional work. Most of a developer's career is spent working on things other people started.

What varies is how long the reading takes. That is the real question, and it is answerable.

What actually makes it hard#

Not the things people worry about.

The language it is written in barely matters. Old PHP, .NET, Python, something unfashionable: all readable. A system being written in a language nobody talks about any more is a supply problem, in that fewer people will want the job, not a comprehension problem.

Messy code barely matters either. Every real system that has been in production for years is messy, including ours, including anything you would consider well built. Tidiness is pleasant. It is not what decides this.

Here is what actually decides it:

Can it be run somewhere safe? If a new developer can stand the system up on a machine where it cannot hurt your business, they can learn it by using it and by breaking it. If the only copy that exists is the live one, every single thing they learn has to be learned carefully, and careful is the expensive setting.

Is the running code the same as the stored code? This is the one that catches people out. If changes were made directly on the server over the years and never put back into the repository, then the code you have is not the code you are running, and the differences are invisible until something behaves unexpectedly.

Can you get into the accounts? Hosting, domain, database, third party services. The reading is the easy part next to being locked out.

Does the data make sense? A database with clear tables tells a new developer what the system does more honestly than any documentation. Data is the record of what actually happened, rather than what somebody intended.

Is one thing doing ten jobs? Systems that grew in a hurry often have one enormous piece of code that handles everything. That is genuinely slower to work with, because nothing can be changed in isolation.

Notice that only one of those is about the code itself. The rest is access, environment and data, which is why an honest assessment starts with questions you can answer yourself rather than with a code review.

How long before somebody is useful#

For a small or medium system in reasonable shape, a developer who knows what they are doing can be making safe changes within a few days, and confident within two or three weeks. A large system with no test coverage and no safe environment takes longer, and the honest range is wide enough that anybody quoting you a precise figure before reading it is guessing.

What should happen first is a read: somebody spends a defined amount of time going through what exists and writes down what they found. That is a small, fixed piece of work and it should be priced as one. Everything after it can then be estimated properly, because somebody has actually looked.

The reason this matters is that it converts an unknown into a known cost. An unknown is the thing that makes people give up on a system that was perfectly salvageable.

About the advice to start again#

You will be told to rebuild. Possibly by the next developer you speak to.

It is worth understanding why that happens, because the usual explanation people reach for is that they are being ripped off, and that is normally not what is going on.

Writing new code is faster, more enjoyable and far easier to estimate than reading old code. A developer can look at a rebuild and see a shape they understand. Looking at somebody else's ten year old system, they see work they cannot size, in a codebase they have no feel for, with a risk of breaking something a business depends on today. Given the choice, most people prefer the job they can price confidently.

That is a human response rather than a dishonest one. But it has a consequence for you: the rebuild recommendation arrives far more often than the facts justify, and it usually arrives before anybody has read enough to know.

So the test is not whether they say rebuild. It is when they say it. A rebuild proposed after somebody has read the system and can tell you specifically what is wrong with it is a real opinion. A rebuild proposed in the first conversation is a preference.

Ask two questions and you will know which one you have. What specifically in the existing system makes repair more expensive than replacement? And what will I lose in the rebuild that I have today? Anybody who has actually looked can answer both in detail. The second question matters more than it sounds, because a working system contains years of small corrections that nobody remembers making and nobody will think to rebuild.

When starting again genuinely is right#

It would be dishonest to write all of that and leave the impression that rescue is always the answer. Sometimes it is not, and these are the cases where we say so.

• The system does the wrong thing now. If the business has changed so much that you would be paying to preserve behaviour you no longer want, you are restoring the wrong building.
• It cannot be run anywhere but where it is, and where it is cannot be maintained. A system tied to a version of something that no longer receives security updates, and which cannot be moved, has a real end date.
• Nothing can be tested and every change is a gamble. Occasionally the cost of changing safely exceeds the cost of replacing.
• It is a small system. If the whole thing is a few weeks of work, the case for archaeology is weak. Read it, take the rules out of it, and write it again.

Even in those cases, the existing system is not wasted. It is the most accurate specification you will ever have of what the business actually needs, which is worth more than any document somebody would write from scratch.

What a new developer will need from you#

None of this is technical and all of it speeds things up.

• Access to the accounts, or the paperwork to recover them.
• A copy of the code and the database, wherever they are.
• The names of anybody who has worked on it. Ten minutes on the phone with the person who built something in 2011 is worth a fortnight of reading, and people are usually happy to help.
• Whatever documentation exists, even if it is out of date and scribbled.
• A short description of what the system does for the business and what would hurt most if it stopped.

That last one matters more than it looks. It tells a developer what to be careful with, which is the difference between cautious work and slow work.

What we do#

This is most of what we do, so we should say where we stand.

We read first and write down what we find, including the case for not spending money with us. If starting again is genuinely cheaper for you, the document will say so, with the reasoning. We would rather write that sentence than take on a system we would be charging you to preserve for no good reason.

The read is a fixed price agreed before it starts, like everything else. After it, the work is priced job by job, and you approve each one before it exists.

Thirty years of doing this means the systems that arrive are rarely surprising. Legacy PHP, Python and .NET, databases carrying millions of rows of history, platforms nobody has touched in a decade. Nothing we open is going to be something we have not already seen, and that is the difference between a quote built on judgement and one built on a guess.

If you are not ready to talk to anybody#

That is reasonable, particularly if the last conversation you had about this cost you money.

Our project healthcheck is twelve questions and takes about two minutes. It does not ask for an email address, and most of what it recommends costs nothing and does not involve us. It will tell you roughly where you stand, which is usually the thing people want before they speak to a single developer.