Main idea

"Just have a developer review everything" is the answer that comes first when a non-technical profile starts producing code. It looks prudent, and it cancels the benefit: if a Product Manager has to pull in a developer to validate the export they just built themselves, they have moved the request, not removed the wait.

Systematic review is not, in any case, a law of software. It took hold first in the open source world, where it answers precise needs — quality, security, knowledge transfer, governance, trust between contributors who do not know each other. Transposed as-is to all of a company's code, it treats an unknown contributor and a colleague building a dashboard for themselves in exactly the same way.

Review keeps two solid uses, and they are different: early on, to pass practices to someone who is starting out; and afterwards, depending on what the object at hand has at stake. What does not hold is its systematic character.

Why it matters

It forces you to state what review is supposed to buy in each case. Depending on the answer — learning, securing, sharing knowledge, committing collective responsibility — the right setup is not the same, and it is not always a line-by-line read.

It also protects a fragile economy: the point of a tool built in two hours disappears if validating it means two days waiting in an engineering team's queue.

Nuances and limits

The argument only holds for objects with low stakes and a short life. It reverses as soon as the object touches production, sensitive data or shared use — and it reverses too when an object that started out throwaway has become something a team has to go through.

It finally assumes that whoever builds can recognize the moment they have left the throwaway regime: that is precisely the judgment they most often lack.

Open questions

• What replaces review when what you were after was not control but the passing on of practices — support at the start, occasional pairing, a sample read?