Four engineers, four architectures

Drift is the default, not a lapse

When one engineer mostly owns one app, that app converges on whatever that engineer finds reasonable. Every individual decision is defensible in context. The problem only becomes visible in aggregate, when somebody has to move — and by then it is months of accumulated divergence rather than a decision anyone can point at.

This is not a discipline failure and treating it as one gets you nowhere. It is what happens when four competent people make good local decisions in isolation. Nobody chose to fragment the codebase; the structure of the work chose it for them.

The symptom that surfaces first is usually staffing. A developer is off, or leaves, or is needed on a deadline elsewhere, and the cost of moving them turns out to be far higher than anyone budgeted. That is the point where a team discovers what its drift actually cost.

Review is the mechanism, not the ceremony

The single change with the most effect was structured code review — every change read by someone other than its author before it shipped. Its value was not defect detection. It was that it forced at least two people to be familiar with every part of every codebase, continuously.

Reviews on a small team drift toward approval theatre unless they have a stated purpose. Ours was explicit: the reviewer is not there to approve, they are there to be able to work on this code next month. That reframes the question from 'is this correct' to 'can I follow this', which is the question that actually catches divergence.

It also changes what feedback is acceptable. 'I would have done this differently' is not useful. 'This does not match how the other three apps handle the same thing, and here is where they do it' is.

Write the standard down, and keep it small

Architecture standards that live in someone's head are not standards, they are preferences with authority. We wrote ours down: layering, where state lives, how navigation is structured, how network calls are made. Short enough that a new developer could read it in one sitting.

Length is the thing to be disciplined about. A long standards document is not read, and an unread standard is worse than none — it gives everyone the impression a decision has been made while the codebase quietly does something else.

Agreement matters as much as content. A standard imposed is followed while you are watching and abandoned under deadline. A standard the team argued about and settled survives contact with a deadline, because they own it.

Mentoring is what makes a standard hold

The part that determines whether any of this survives is the junior developers. A standard holds when the people newest to it understand why it exists, and stops holding the moment it is followed as a rule with no reasoning attached.

The practical version of that is explaining the failure a convention prevents, not just the convention. 'State lives outside the widget tree' is a rule to be forgotten under pressure. 'State lives outside the widget tree because otherwise rebuilds trigger fetches and the app degrades over a session' is a thing somebody can reason from when they meet a case the standard does not cover.

This is also the slowest part, and it is the first thing dropped when a deadline arrives. Dropping it does not show up for months, which is exactly why it keeps being dropped.

What I would do earlier

I would rotate ownership deliberately, and much sooner. Everything above is a way of mitigating the effects of one engineer owning one app; rotation attacks the cause.

It is genuinely slower in the short term and that is the honest reason it did not happen sooner. A developer working in an unfamiliar codebase ships less that week, and when four apps are all mid-delivery, that cost is easy to see and the drift cost is not.

The thing I did not appreciate early enough is that review, written standards and mentoring are all ways of paying that cost in smaller instalments. If you are not going to rotate people, you are going to pay for it in orientation time later — the only question is whether you pay deliberately or all at once when somebody leaves.

Individual features from that period shipped and were later replaced. The review habit and the layering the team agreed on outlasted them, which is why I list it as work rather than as a job title.