A Newcomer's First Change Should Not Need a Senior Engineer's Memory. The Benchmark We Would Set.

The engineer joined three months ago and is good. Everyone says so.

In three months they have fixed two spelling mistakes on a screen and changed nothing else. They are not idle. They read the old code every day. But each time they find the line to change, they stop. They cannot tell what else uses it, and there is nothing they can run that would say.

So they ask a senior engineer, who reads the change, thinks of three other places it might touch, and says to leave it for now.

What We Found

For this article we went through the public record on how changes to old code are checked: one survey of developers who work mainly in PHP, one developer’s own account of working on old code, and one engineer’s post on a developers’ forum about documentation drafted with AI tools.

Three findings stand out.

Many products have nothing to check a change against. In one survey of more than 1,700 developers who work mainly in PHP, a widely used web language, about a third said they still write no tests at all. The survey is about developers in general, not about software firms alone, and it covers one language.

Without tests, a first change is frightening. One developer, writing about old code, said nothing is more frightening than changing a critical old system that has no tests. It is one person’s account. It describes the newcomer in the opening scene: capable, careful, and unable to see what a change will touch.

A record is only useful if someone checked it. One engineer, writing on a developers’ forum about documentation teammates had produced with AI tools, said that sometimes no document is better than a bad one. The same post describes checking the documents against the code. It is one person’s account, and we use it for one point: whatever drafts a record, engineers have to check it before a newcomer relies on it.

Our reading is that a new engineer on an old product is rarely slow. They have no way to check their own work, so the check is a senior engineer’s memory. And memory does not scale: it is busy, it forgets the report nobody opened for a year, and it leaves when the person does.

What Waits While Every Change Goes Through the Same Few

A firm whose newcomers cannot check their own changes does not stop changing the product. It changes it more slowly, and always through the same people.

The first cost is the queue. Small changes customers ask for wait behind large work, in one senior engineer’s review list.

The second cost is the hire itself. A good engineer who changes almost nothing for months is paid for, and is losing heart.

The third is that nothing improves. When the senior engineer checks a change from memory, nothing is kept that would let the next newcomer check their own.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Check a Newcomer’s First Change, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
A senior engineer reads every change from memory	Newcomers are rare and the product is small	Every change queues for the same few, and what they forget reaches customers
Keep newcomers shadowing until they know the product	The firm can wait months for each hire to start	The newcomer learns the surface, never gains a way to check their own work, and may leave
Write tests for the whole product before anyone changes it	The firm can pause other work for a long time	Months of work before the first change, on parts that may never change
Write down what the product does, record today’s behaviour as tests for the modules newcomers change first, and rebuild modules on a current stack over time	The product is large and old, and new engineers keep joining	It costs effort at the start, your senior engineers are needed to confirm it, and your own team must keep the tests current

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Functions of the product written down	Few or none; the code is the record	Every function in plain words, confirmed by your own people	The specification
People able to explain each module	Two or three, for the oldest modules	More than a few for every module, working from the record	The map of the product, reviewed at each stage
Modules on a current stack	None, or only the newest parts	Rising at every stage, with a date for each	Reported at every review
How a newcomer’s first change is checked	A senior engineer reads it from memory	The tests pass, and any difference is explained against the record before release	The record of each change
Behaviour recorded as tests, for the modules newcomers change first	Few or none	Each such module covered, including the awkward cases support staff know	The test run, shown against the specification

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a software firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your product, how a new engineer’s changes are checked today and who checks them. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code, and the assessment marks the modules newcomers are most likely to change first. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. Here that means tests that record what those modules do today, handed to your engineers with the specification so that a newcomer’s change can be checked against them. Where a module is to move to a current stack, we replace a system one module at a time while the old one keeps running. We never do a single cutover. Each rebuilt module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each stage we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits. Tests show that the product behaves as it did; they do not show that it was right, and they will protect an old fault until someone rules on it. They cover the cases that were recorded. We are not a staffing firm: we do not supply, recruit or train your engineers, we give no advice on pay or employment, and nothing here promises that anyone will stay. We have no assistant that answers questions about your code. We do not convert code by machine; what we rebuild is a web application on React, Node.js, Python or Java. We do not maintain the product, the record or the tests afterwards; your own team keeps them current. A senior engineer’s review still matters for anything large. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	A new hire starts adding to the product sooner, and the firm is less exposed when someone leaves.
CTO or CIO	Tests that say what the product does today, so a newcomer’s change can be checked without a senior engineer reading every line.
Head of product	Small changes customers ask for can be given to more of the team, and stop waiting for a senior engineer’s free day.
CFO	Senior engineers’ time goes to the work only they can do, and less of it to checking other people’s first changes.
Head of people	A new engineer has a safe way to begin, and is not left watching for months.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. Its figures come from a survey of developers, one developer’s account and one engineer’s forum post.	We write down what your product does and record what its first-change modules do today as tests your own engineers can run. We do not train your staff or keep the tests current afterwards.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We hand your engineers a record of what the product does, so a newcomer’s first change can be checked by the tests, not by someone’s memory.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →