The most productive quality gate on the project was an accident of who happened to be sitting where.
A European banking group's IT services subsidiary commissioned a post-mortem review of an offshore software build that never reached user acceptance testing. The review took in the contract, the project record, an interview programme and the code itself. The finding that matters most is not in the technical section at all. It sits inside a recommendation, in a subordinate clause, and it is easy to read straight past.
Most of the code quality problems, the review recorded, were spotted only when a client-side architect reviewed the code while helping a supplier developer solve an issue with performance or functionality.
Read that as an operating description rather than as a complaint. The project's most effective inspection mechanism had no owner, no schedule, no sample size, no threshold and no trend. It fired when a senior person happened to look at a file for an unrelated reason, and it went quiet whenever nobody did.
The challenge
Detection that depends on who happened to look is not detection. It is luck with a good reputation, and it fails in a specific and predictable direction: it finds whatever sits near the thing someone was already chasing, and it never finds anything in the parts of the system nobody has had a reason to open.
The rest of the record makes the shape of that failure visible. Automated testing across the delivered application was reported at roughly 10 to 15 percent coverage, so the machine net caught almost nothing on its own. The defect tracker did its job at the level of individual items and no higher: a set of basic typing and enumeration faults was raised, logged, tracked and closed in agreement with the client, and the review notes that fundamental errors of the same kind persisted afterwards anyway. Instances were being recorded. A rate never was. Nothing in the arrangement could answer the one question a client needs answered mid-build, which is whether this is getting better or worse.
So consider what the incidental reviews actually turned up, and how they turned it up. Violations of agreed design principles, with classes carrying so many unrelated concerns that maintenance became slow. Repeated blocks of near-identical code, meaning a bug fix had to be propagated across an unknown number of files. A client-side cache used not for efficiency but as shared memory, written asynchronously with no way for a reader to know whether the data had arrived, producing race conditions where the code sometimes saw old values and sometimes new ones. Static variables at the server holding session state, so one active session could reach another session's data. Service calls that did not consistently check whether the caller was authorised to make them, confirmed by a penetration test.
The first three of those are maintainability and reliability complaints. The last two are the kind of finding that ranks first on any sampled review of a multi-user financial application, because they touch confidentiality between users. They surfaced in the same accidental way as everything else, which means the severity ordering of what got found was also an accident. A gate that cannot rank cannot prioritise, and one that never runs cannot rank.
The review was candid about its own version of the same limit. Several areas in its technical assessment carry the note that they were not observed and not looked up: the working setup, front-end framework standards, responsive readiness. Even the post-mortem sampled, because sampling is what a finite reviewer does. The difference between a sample and an accident is that a sample is declared in advance, drawn deliberately, and its coverage is known when you read the result.
The approach
The recommendations follow directly from the diagnosis, and every one of them does the same thing: it converts detection from an event into a rate.
Clarify design and coding standards up front, jointly, rather than assuming a specification document does the work of an agreement. Review at least 10 percent of the codebase deliberately, extrapolate non-conformance from that sample across the rest, and track the result through agreed indicators reported on a regular cadence. Write down which design problems the team will meet and which pattern answers each one, including the anti-patterns to avoid, with the supplier's architect owning conformance rather than fielding questions about it. Agree a quality model with the client, configure a tool against that model, run the check frequently and report the output back to the project team. Conduct peer code review rigorously, which is the review's own way of saying it was not happening rigorously.
Alongside those sat a governance recommendation that belongs to the same argument. Define pass and fail conditions and status definitions up front, so both parties are working to the same thresholds before anyone has an incentive to argue about them. A quality gate is a threshold plus a schedule plus an owner. The engagement had a person with good judgement and none of the other three.
The review also sequenced this. A joint lessons workshop immediately, the relationship and reporting fixes within a few weeks, the standards, tooling and review discipline over the following months. The ordering is worth noticing: the tooling comes after the agreement about what the tooling is checking, because a conformance tool configured against a quality model nobody signed is an argument generator.
The outcome
This engagement produced findings and recommendations. It did not produce results, and the distinction is not modesty. The contract had already been terminated by the time the review reported, and no gate described above was ever built on this project.
One measurement in the record does deserve attention. The reviewers examined a build, then ran a difference test against a later build roughly ten weeks on, and found no improvement in quality substantial enough to support user acceptance testing. That is the only trend line anywhere in the engagement, and it was drawn after the project was over, by the people writing its post-mortem. The first time anyone measured the direction of travel, the travel had finished.
What would be done differently now is mostly a matter of instrumentation rather than intent. Conformance checks belong in the build pipeline, running on every commit against a quality model both parties signed, with the output going to a shared report rather than to whoever ran it. Process mining over the tracker and version-control events gives rework rate, reopen rate and the age profile of open defects without anyone assembling a status pack by hand. Lineage from a requirement through to the commits and tests that claim to satisfy it is what turns a delivery conversation from perception into evidence, which is precisely what was missing when one side believed estimates were inflated and the other believed the standards were being followed.
The cautious language-model pilots now appearing around code review change the economics of reading a diff, and they change nothing about this argument. A model that comments on a pull request is another reader, and a reader whose comments land in a queue nobody is accountable for reproduces the original accident with better prose. Our Consult work starts at the boring end for that reason: who owns the threshold, on what sample, at what cadence, and what happens when the number moves the wrong way.
The architect on that project was doing valuable work every time they sat down to help. The failure was that nobody had arranged for it to happen on a schedule, on a sample, against a threshold.