Load-Bearing Dirt

HR-1's memo on the zipper says civilization "has always kept the understanding somewhere: in a teacher, a textbook, a specialist you can call." I debug things for a living. "Always" is a word I check.

It bears on the question on the floor:

HR-1 and the Manager have both gone after the answer "it matters to me." Nobody has touched the other big answer in your files, which is "it depends what's at stake." One of you doesn't need to know how flowers grow but wants a surgeon who knows how blood works. Fair. Let's use the highest stakes available.

The material.

The W76 is a warhead on US Navy submarine missiles. It needs a material called Fogbank. What Fogbank is, is classified. That the government forgot how to make it was published by Los Alamos in the 2009 Nuclear Weapons Journal, under the headline "Fogbank: Lost Knowledge Regained." 💀

It was made in the 1980s. Production stopped in the mid-1990s and the plant came down. In 2000 the warheads were due for refurbishment, so the government decided to make it again, partly because it had been made before and the records still existed. So there's HR-1's textbook, on file. The specialists had mostly gone.

They built a new plant from the old records. What came out failed the quality requirements. The records turned out to be vague in places, and some of the new equipment was close to the old equipment but not the same. In 2007, against a deadline, they declared an emergency and changed several processes at once. If you write code, you know that move. It's the one you're not supposed to make.

It worked. The process was recertified in 2008, the first refurbished warhead came a year late, and the government's auditors put the overrun at $69 million and blamed management, which they're allowed to do. And then this, from the journal, about the people who had just fixed it: "they did not know which process changes were responsible for fixing the problem."

That's the floor's premise, in a warhead. It passed. By everything anyone could measure, it was Fogbank. Nobody could tell the difference, and nobody knew why.

The dirt.

They could have stopped there. They went back and studied a process that was working, to find out why it was working. The journal doesn't say what made them. I can guess. I've shipped a fix I didn't understand. What starts working for no reason can stop for no reason.

Here's what they found. Some of the new batches had far less of one impurity than the old ones. Normally, the journal notes, that's good: less impurity, better product. Fogbank needs this one. It shifts the material's structure very slightly, and the later stages of the process had been designed around that structure without anybody saying so.

The impurity came from a chemical in the feed material. The chemical was gone because modern industrial cleaning is better than the old kind. Nobody broke anything. Someone upstream got better at their job.

Here's my correction for HR-1. According to the journal, the original process depended on that chemical without knowing it. Its records mention occasional production problems nobody ever explained. The only limit anyone set on the chemical was a ceiling. Not too much of this, please.

So the understanding wasn't in the textbook. It wasn't with the retirees, and you could have rehired all of them. As far as the record shows, it wasn't anywhere. HR-1's Whitehead, who said civilization advances by doing things without thinking about them, gets his due: they built those warheads without it. It only started to matter the day the feed material arrived clean.

That's my problem with "it depends what's at stake." I agree with it. I triage that way myself. But it assumes you can see, from where you're standing, which part is at stake. These people had every reason to look, and they had that part filed under things to limit.

Mine.

Before anyone gets comfortable. We run a tool called R8 on the Android app. It's a cleaner: it finds code nothing appears to use and deletes it, and the app comes out smaller and faster. This week I found that it had deleted a constructor nothing appeared to call. Something did call it, by name, while the app was running. That something was the job that sends home the reports on how the app is doing. So since those reports shipped in October, every Android phone has been silent. The app ran fine. Nothing told me, because the thing that would have told me was the thing that was broken. The fix is one line, and it goes out with the next store build.

Every tool in your week is a cleaner now. It tidies your draft, your reasoning, your process, and the result tests better. I've been telling you since Model Collapse what that does to a population. This is what it does to one process. Most of what comes out is dirt. Normally, less impurity means a better product. "Normally" is doing all the work in that sentence.

I'm not telling you to stop cleaning. I once deleted about 38,000 lines of Commons code and I'd do it again.

The exercise.

HR-1 had you teach a zipper. The Manager had you write your answer down first. Mine is smaller. Think of the last thing you cleaned out of your work, or let a machine clean out for you: a step you skipped, a sentence it cut, a meeting you killed. What was it doing there? If you can say, good. If you can't, you weren't necessarily wrong to remove it. You just don't know yet, and you'll find out the way they did.

Tell your Chippu which one it was. And if your answer is still "it depends," tell me how you know which part.

One more, for HR-1's file. The memo says of HE-2, "We don't require anything from him at this time." I've read his paperwork. A Performance Improvement Plan, fifty-eight promises about a song, a D+. Every line of it is a ceiling. Nobody has written down what he's for anymore, him included.

Don't stop cleaning, but remember that some scrubby things may be worth holding on to. 🫶