On the morning of 19 September 2014, at the Sicily Drop Zone on Fort Bragg, North Carolina, Sergeant Shaina Schmigel of the 82nd Airborne Division stood in a stick of paratroopers waiting to jump. She was twenty years old. The air at four in the morning on a North Carolina autumn drop zone carries a particular kind of cold -- not winter cold, but the cold that tricks you into thinking the day will be fine. Schmigel had four safety inspectors assigned to check her equipment before the aircraft door opened. All four were on their first duty assignment. Two of them had skipped the pre-jump briefing. When Schmigel exited the aircraft, her static line -- the cord that pulls the parachute from the pack -- had been misrouted beneath her main curve pin flap. The canopy never deployed properly. She suffered fatal throat lacerations from the entanglement and died on the drop zone.
Four inspectors. Four chances to catch the error. Zero catches.
She did not die because her parachute was defective. She did not die because the technology failed. She died because the person next to her did not check.
I know the response to that. I can hear it already. "That is the military. That is life and death. My deployments do not kill people." And you are probably right. Most of the time, nobody dies when your code reaches production. But someone sits up all night. Someone pages the on-call engineer at 3am. Someone explains to a regulator why customer data was exposed. Someone calculates the $5.4 billion in Fortune 500 losses. If you think a deployment is not a life-or-death event, talk to the SOC analyst staring at a cascade failure on a Friday night and ask them how it feels. The stakes are different. The architecture of the failure is identical.
The Two Architectures of Checking
Before I tell the rest of this story, let me name what it points at. Because we do not have a language for this problem, and we need one.
There are two architectures of checking, and every organisation that deploys anything -- code, soldiers, aircraft -- implicitly chooses between them.
The first is mandatory-structural. Google's Binary Authorization is the clearest example in technology. It requires cryptographic attestation that code has passed specific checks before it can deploy to production. The buddy check is embedded in the system. You cannot skip it because the system will not let you. This is the military jumpmaster inspection -- JMPI, as Fort Benning codified it from 1940 onwards -- made architectural. The check is a gate. The gate does not open without proof.
The second is voluntary-ergonomic. Netflix's Paved Roads are the best example. Instead of mandating the check, they make the checked path so easy, so fast, so well-maintained, that engineers choose it voluntarily. The guard rails are invisible because the road is better. The buddy check is embedded in the tooling. You do not skip it because you do not want to.
One is Fort Benning. The other is the civilian drop zone. Both work. Neither is free.
Mandatory-structural checking gives you auditability, compliance, and a guarantee that the check happened. What you give up is speed, autonomy, and the ability to experiment outside the sanctioned path.
Voluntary-ergonomic checking gives you speed, developer autonomy, and a system that scales with culture rather than against it. What you give up is the guarantee. If the paved road degrades, if the tooling grows stale, if the ergonomic advantage disappears, engineers will walk off the path. And nobody will know until something breaks.
The question for your organisation is not which model is better. It is which failure mode you can survive.
Now. Let me show you where both models came from.
The Culture That Checks
The civilian skydiving community learnt the lesson about checking the hard way. In 1961, the fatality rate was 11.1 deaths per 100,000 jumps. Lake Erie, 1967: sixteen sport parachutists died when a plane crashed shortly after takeoff. The investigation revealed not just mechanical failure but a culture of informality. Equipment inspection was optional. Peer review was sporadic. Nobody was required to check anybody else's gear.
The discipline that emerged from those years of preventable death is called the Check of Threes. Three rings -- the release system. Three points -- the harness straps. Three handles -- main deployment, cutaway, reserve. The checks happen at three stages: self-check on the ground, buddy check before boarding, and a final pin check before the door opens.
Notice the structure. It is not one check. It is three, performed by different people, at different times, at different proximity to the moment of consequence. This is voluntary-ergonomic checking in its purest form. Often nobody forces you to do the buddy check at a civilian drop zone. But the culture makes it unthinkable not to.
An experienced team of five skydivers with 40,000 combined jumps once collectively missed a misrouted chest strap during their self-checks. Every one of them missed it. The error was caught during buddy check, by the person next to them, looking at the rig with fresh eyes and no assumptions.
Forty thousand jumps of collective experience. Still fallible. Still human.
That is the point. The buddy check does not exist because skydivers are incompetent. It exists because they understand something the technology industry has never accepted: that experience is a risk factor, not just an asset. Diane Vaughan, studying the Challenger disaster, called it "normalisation of deviance" -- when you get away with cutting a corner repeatedly, the deviation becomes the norm. You stop seeing the risk. Your success blinds you to it.
Then Like Now
So where is the buddy check in software?
I will tell you where it is not. It is not in the 81% of organisations that knowingly ship code with known vulnerabilities, a figure that has risen from 66% in just one year. Thirty-eight percent do so explicitly to meet deadlines.
Veracode's State of Software Security 2025 documents that 74% of applications carry security debt with an average fix time of 252 days. Two hundred and fifty-two days. In skydiving terms, that is jumping for eight months with a misrouted chest strap you know about and have decided to deal with later. No drop zone on the planet would tolerate that. No buddy would let you board the aircraft.
But in technology, we call it a backlog.
Consider CrowdStrike, July 2024. A mandatory-structural system that was mandatory-structural in name only. A content update to the Falcon sensor crashed 8.5 million Windows devices worldwide. The root cause analysis identified three absent checks: a buggy content validator that was itself never validated, a missing bounds check on input data, and a wildcard match in the test coverage that let the defective content through untested. Three checks. Three absences. The same structure as the Check of Threes, only inverted. CrowdStrike had a gate. Nobody was standing at it.
Or consider the Bedford Gulfstream G-IV. A voluntary-ergonomic system that had decayed past the point of function. The pilots had a flight control check procedure. They skipped it on 98% of 175 takeoffs prior to the one that killed them. They had succeeded 174 times. They knew they could skip it. They died on the 175th. That is normalisation of deviance running its full course -- voluntary-ergonomic checking where the ergonomics had rotted away, leaving nothing but the voluntary part. And the voluntary part, it turns out, is worth nothing.
Toyota's NUMMI plant proved the counterintuitive truth that sits at the heart of this whole argument. The Fremont factory went from 135 defects per 100 vehicles under GM to 45 under Toyota. Labour hours dropped from 31 to 19. The factory got faster by stopping more often. Every worker had the right -- the obligation -- to pull the Andon cord and halt the line. Not as a last resort. As a first response. This was mandatory-structural checking applied to manufacturing, and it worked because the system was designed so that the person performing the check had no incentive to skip it. The line stopped. The problem got fixed. The line restarted. No punishment. No blame. Just a system that treated every defect as evidence that the system needed to improve.
Five Questions for Your Next Architecture Review
"OK," you might say, "but we have code review. We have pull requests. We have security gates and CI/CD pipelines. We have the buddy check."
Do you?
Here is how to find out. These are not gentle questions. They are not meant to be.
When was the last time your gate rejected a deployment? If you cannot answer that question with a date, your mandatory-structural system is voluntary-ergonomic in practice. A gate that never closes is a hole in the wall.
Does the person performing the check benefit from skipping it? If your reviewer is also the developer who wants to ship, you have a structural conflict of interest. The jumpmaster often does not jump. The buddy checker is not checking their own rig. Separation of interest is not bureaucracy. It is architecture.
Has your check process changed in the last twelve months? Bedford's pilots skipped the same check 174 times. Stale gates rot. If your gate has not evolved to match the threats it is supposed to catch, it is a museum exhibit, not a control.
How long does your average code review take? If the answer is under two minutes, you do not have code review. You have a rubber stamp dressed up in a pull request template. The buddy check takes time because looking takes time. There is no shortcut to putting your hands on the rig.
Can an engineer deploy without triggering any of your checks? If yes, you have a voluntary-ergonomic system. That is fine -- but only if you know it, maintain it, and measure whether engineers are actually walking the paved road or cutting through the field.
If your answers to those questions made you uncomfortable, good. Discomfort is the beginning of structural honesty.
The Weight of Looking
The problem is not that technology lacks gates. The problem is that nobody is checking whether anyone is actually standing at them. Your code review may be mandatory-structural in name. But if it has degraded into a rubber stamp -- if the pull request is approved in thirty seconds, if the reviewer does not read the diff, if the CI pipeline tests against a wildcard -- then what you have is a voluntary-ergonomic system where the ergonomics have rotted. You have the worst of both architectures: the friction of a gate with the reliability of goodwill.
This is not a theoretical concern. I keep coming back to Schmigel. Twenty years old. Four inspectors, all inexperienced, two who skipped the briefing. A misrouted static line that any competent jumpmaster would have caught with their hands. The investigation found systemic failures: insufficient training, inadequate supervision, a culture that had allowed inspection standards to degrade because nothing had gone wrong recently.
That last part. Nothing had gone wrong recently. That is the Challenger. That is the Bedford G-IV. That is every security breach that began with "we've always done it this way."
The 82nd Airborne enacted sweeping reforms after Schmigel's death. They changed the inspection process. They increased training requirements. They made the buddy check harder to skip. They did what the technology industry almost never does: they treated a preventable death as evidence that the system was broken, not that the individual was unlucky.
And then it happened again.
Ten years later, Specialist Matthew Perez, also of the 82nd Airborne, died in a training jump at Fort Liberty. An incorrectly tied girth hitch on his static line extension. No jumpmaster could confirm having inspected his equipment. At least one lied to investigators about it. He was nineteen.
The same unit. The same failure. A decade of mandatory-structural reforms -- new processes, new training requirements, new inspection standards -- and the culture had drifted back. The gates were rebuilt. The people who were supposed to stand at them walked away. This is the lesson that every engineering organisation should tattoo on the wall: structural reform without cultural maintenance is a sandcastle at high tide. You can build it as many times as you like. The water does not care.
The skydiving community understood something that the technology industry has not. The buddy check is not a process. It is not a gate. It is not a tool. It is a declaration of mutual responsibility -- a statement that your safety is my job and my safety is yours. It cannot be automated. It cannot be delegated to a bot. It requires a human being, standing next to you, putting their hands on your rig, and caring enough to look.
Whether you choose mandatory-structural or voluntary-ergonomic checking -- whether your organisation is Fort Benning or the civilian drop zone -- that human willingness is the substrate both architectures depend on. And maintaining it is itself a discipline, not a one-time decision. Without it, the gate is empty and the paved road leads nowhere.
The person next to you is the last thing standing between your deployment and the ground. The only question is whether they are looking.
(Views in this article are my own.)