Why it pays to keep a developer who already knows your code

A billing bug gets reported on a Tuesday morning. Twelve customers have been charged twice. You need it fixed today, and you need to know it will not happen again on Friday.

The question is not who can write the fix. Plenty of people can write the fix. The question is who knows where to look, which of the four places that handle payments is the real one, and whether the odd-looking line of code next to the bug is a mistake or the thing holding a customer contract together.

That knowledge is the asset. Not the code, not the server, not the ticket system. The knowledge of why your software is shaped the way it is. It is the most expensive thing you own and the only thing you cannot back up.

What the knowledge actually looks like

Here is a real shape of the problem. Somewhere in a system there is a line like this:

if ($account->created_at->lt('2019-04-01')) {
    $rate = 0.125;
}

A capable developer seeing that for the first time has no way to tell whether it matters. There is no comment. The commit message says "fix rates". It looks like dead code from an old promotion, and deleting dead code is good practice, so it gets deleted.

Three customers are still on the old contract. They are your three largest. Nobody notices for two months, at which point you are having a conversation about credit notes and trust.

Someone who has worked on that system for two years does not need to work any of this out. They know, in the same way you know where the light switch is in your own house. The lookup is instant and free. For everyone else it is an investigation, and investigations get billed.

The cost you are already paying

If you bring in a new contractor for each piece of work, you pay for that investigation every time. It does not appear as a line on the invoice. It appears as the first two weeks being slow, the estimates being cautious, and the recommendation being "rewrite it" because a rewrite is easier to price than an unfamiliar system.

It also appears in the decisions. A developer without context makes safe, local choices. They fix the bug in front of them rather than the thing causing it, because fixing the cause means touching code they do not understand. Each of those decisions is defensible in isolation. Together, over a couple of years, they are how a system becomes the thing nobody wants to work on.

This is not a criticism of contractors. It is the rational response to being dropped into a codebase with a fixed budget and no history. You would do the same.

Software does not sit still while you ignore it

There is a belief that working software can be left alone. It cannot, and the reason is that everything underneath it keeps moving.

PHP is a good example. In PHP 8.4, writing a parameter like function send(Mailer $mailer = null) became deprecated, because the nullable type is now expected to be written explicitly. That is a small change. It is also in hundreds of places in a codebase of any age, and it fills your logs with warnings until someone deals with it. PHP Watch documents these version by version, and there is a list like it for every release.

Laravel ships a major version roughly once a year, with security fixes for about two years after release. Miss three of those and you are not doing an upgrade, you are doing a project. The same is true of every library your application depends on, and a typical Laravel application has a few hundred.

This is not housekeeping. Outdated components are their own category in the OWASP Top 10, and they are one of the most common ways a business gets breached: not a clever attack, just a known flaw in a package that had a fix available for eighteen months. The NCSC says the same thing in language written for boards rather than engineers. Keeping software patched is the cheap half of security.

Somebody has to do this work, and it has to be somebody who can tell the difference between an upgrade that is routine and one that will take a fortnight.

What a retainer should actually buy

A retainer that is only an emergency number is a bad deal. You pay every month and get nothing most months, and when you finally call, the person on the other end has not looked at the system since February and no longer knows it.

A retainer works when the guaranteed time is spent on things that keep the knowledge current:

• Dependency and framework updates, done in small increments rather than saved up.

• Watching the error logs and the slow queries, and dealing with the ones that are getting worse.

• Restoring a backup to a test environment, properly, at least twice a year. Backups that have never been restored are not backups.

• Being in the room when you are deciding what to build next, before the decision is made.

That last one is where most of the value sits, and it is the one people skip. The cheapest work is the work you do not do. Someone who knows your system can tell you that the feature you are scoping already exists, half built, behind a flag, and that finishing it is three days rather than three weeks. Nobody can tell you that from the outside.

The honest downsides

There are three, and you should plan for all of them.

The first is the obvious one: you are paying in quiet months. Some months the retainer buys you patching and a couple of conversations. That feels like waste. It is the same trade as a service contract on a lift. You are paying to not be surprised.

The second is concentration. If one person holds all the context, you have moved the risk rather than removed it. The answer is to insist that decisions get written down as they are made, in the repository, in plain English, and that a second person can deploy and restore the system without help. Ask to see that, do not take it on trust.

The third is the most awkward. Someone who has worked on a system for years is attached to it. They may defend choices they made in 2021 that no longer fit. Good ones know this about themselves and will tell you when the honest answer is to replace something they wrote. It is worth asking directly: what in here would you do differently now, and why haven't we?

Retention is cheaper than hiring, and you already knew that

In the 2024 Stack Overflow Developer Survey, technical debt came out as the thing developers are most frustrated by at work. That is worth sitting with. The condition your codebase is in is a retention issue, not just a delivery one. People leave systems that are miserable to work on, and when they leave they take the context with them, which makes the system more miserable for the next person.

Keeping one senior person engaged with your code on an ongoing basis is usually cheaper than a recruitment process, and it is much cheaper than the twelve months of reduced pace that follows losing your only source of context.

What to check this week

Ask three questions and write down the answers.

If the person who knows your system most deeply were unavailable for a month, what could you not do? Deploy? Restore? Change a price? If the list is long, that is your actual risk register.

When was the last time a dependency update was applied, and who decided it was safe to skip the ones since? Run composer outdated if you have access, or ask for the output. You are not looking to understand it, you are looking at how long the list is.

Who is in the room when you decide what to build, and do they know what is already in the system? If the answer is nobody, you are paying for the same thing twice more often than you think.