Don't change anything yet. First get it running somewhere safe exactly as it is. Then map what it does and which parts matter most to the business, and put automated tests around those parts before you touch them, so every change can be checked. Rewriting it from scratch is tempting, and usually the most expensive way to find out what the old code was doing.
What's the problem
You have the code, or someone you've hired does, and nobody can explain it. There's no documentation, the person who wrote it is gone, and every change seems to break something somewhere else. The longer it sits, the scarier it gets.
Why it happens
- Reading code is harder than writing it. Code that makes perfect sense to its author looks like a mess to the next person, even when it works.
- The knowledge was never written down. Why things are the way they are, which odd-looking parts are workarounds for real problems, how to deploy it: all of it left with the author.
- There's nothing to catch mistakes. Without automated tests, the only way to know a change didn't break something is to try everything by hand. So people stop changing it.
- It has aged. Old dependencies, old tools, and services that have moved on. See everything in my project is years out of date.
How to fix it
- Get access to everything first: the code with its full history, and every account it runs on. See what should my developer hand over.
- Get it building on a clean machine, and write down every step. That list becomes the README the project never had.
- Run it in a separate environment, with test data, not on the live system.
- Map it. The main user flows, where they live in the code, the database tables they touch, and every outside service it calls.
- Put tests around the flows that matter (sign-up, login, payments, whatever earns money) that record what the code does today. They're your safety net.
- Change things in small steps, checking the tests each time. Update dependencies one at a time.
- Replace parts gradually, not all at once, when parts do need replacing. The old system keeps working while the new one takes over piece by piece.
When to call Preventionlabs
Taking over unknown code is most of what we do. The free assessment gives you, in writing, what the project is, what's broken, what's missing, and what it takes to get it live. If we take it on, we get it running, protected and scalable, and the handover includes plain-language documentation of how it fits together and how to run, deploy and scale it, so the next person doesn't inherit the same mystery.
Submit your project for a free assessmentFree assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.
Sources
- Joel on Software: Things You Should Never Do, Part Isoftware engineering essay
It’s harder to read code than to write it.
- Joel on Software: Things You Should Never Do, Part Isoftware engineering essay
The idea that new code is better than old is patently absurd.
- Martin Fowler: Strangler Figsoftware engineering reference
What this approach does do is make both investment and returns occur gradually and visibly