The problem
There's one developer who knows how everything works. They built most of it. Every question goes to them, every tricky change waits for them, and nobody likes to think about what happens when they go on holiday.
When they leave, and eventually they do, the knowledge leaves with them. The next developer finds code that works but that nobody can explain. Why is this done in such a roundabout way? Is it safe to change? Nobody knows, so they work around it, and the system gets a little harder to understand each time.
It isn't that person's fault. It's what happens when code is written and understood by one person, and the reasons behind it only exist in their head.
What we do
Code review
Every change is reviewed by another developer before it goes in. No exceptions, and that includes changes made by the directors.
The reviewer is checking that the change makes sense, but they're also learning it. By the time it's merged, at least two people understand it. Over months, that spreads knowledge of the whole system across the team, so no part of it belongs to one person.
Consistent code
Code is formatted and laid out by tools, automatically, to one standard. Nobody's personal style survives, which is rather the point. Every file reads as if the same person wrote it, so moving from one part of the system to another doesn't mean learning a new dialect.
It also means reviews are about the decisions that matter, not where the brackets go. We write code for the person who'll read it in six months' time. Quite often that's us.
Written-down decisions
Code says what the system does. It rarely says why. So when we make a decision that matters (why this database, why this part is done the long way round, what else we tried) we write it down next to the code, where the next developer will find it.
Years later, "why is it like this?" has an answer. Sometimes the answer is "because of something that's no longer true", which tells you it's now safe to change.
Leaving your team stronger
If you have your own developers, we work alongside them. They review our code and we review theirs, so they know every part of the system we've touched. The goal is always to leave your team more capable than we found it.
What it means for you
Nobody is irreplaceable, in the good sense. Holidays, departures and new starters don't put the system at risk. And a new developer can make a real change on their first day. One of ours did.
Start a conversation
Tell us what you're running and where you want it to go.