The Quiet Machine

Brandon Cowen writes and maintains a piece of software called plait. It decides what order other programs do their work in. It is about nine thousand lines long, it has one maintainer, and in nine years it has never earned him a dollar. He would like you to know that almost nobody notices it, and that this is the point.

At twenty past six on a Tuesday morning in January, the room where he does it — a back bedroom on Ferris Street with a desk made out of a solid-core door and a window that looks at the side of a garage — has two occupants. One is a rescue shepherd mix named Otter, asleep against the radiator with the specific completeness of a dog who has already been out. The other is Cowen, in a grey fleece with a broken zipper pull, drinking black coffee out of a dented steel thermos he has owned since 2011. There is a whiteboard behind him covered in what turns out to be a list of things to delete.

I had asked, in the email that got me here — here being Port Alden, a lakefront town of twenty-eight thousand an hour west of Toronto — whether he would talk about disruption in developer tooling. He said yes to the interview and no to the word, and then, when I arrived, said it again out loud.

“Disruption means somebody loses,” he said. “In software the person who loses is usually whoever was maintaining the old thing for free, at eleven at night, for eight years, while everybody else was busy. I’m not interested in being the reason that happens to somebody.”

This is a fairly standard thing for a software person to say. What is not standard is that Cowen said it once, flatly, and then would not say it again, no matter how many openings I left him. Over eleven hours across two days he declined roughly a dozen invitations to be interesting about himself. He is a difficult man to write a profile about, which is probably why he agreed to one.

§

What Brandon Cowen Learned From Things People Threw Away

The origin story is not a garage in the metaphorical sense. It is an actual rented garage two blocks off the harbour, and what happened in it in 2009 was that a twenty-year-old with no computer science degree started buying dead electronics by the crate and finding out which ones weren’t.

“Everything I bought was described as broken,” he said. “About sixty percent of it wasn’t broken. It had one failed component, or a firmware state nobody knew how to clear, or a connector furred with corrosion because this is a lakefront town and nothing here is ever properly dry. The seller had already decided the thing was worthless. That decision was the most expensive part of the whole transaction, and it happened before anybody looked.”

He did that for eight years, alongside contract engineering work he taught himself in evenings, and he says it gave him the only framework he has ever used professionally: that a system written off as dead is usually a working system with one bad joint, and that finding the joint is unglamorous, patient work that almost nobody wants to do.

When he describes the build systems that his scheduler ends up inside — mostly old, mostly patched, mostly inherited from somebody who left the project years ago — he uses the same sentence structure he used about the crates. Written off. One bad joint.

A task scheduler, in this narrow sense, is not the thing that does the work. It is the thing that decides the order the work happens in. Software is built out of steps that depend on other steps: you cannot run the tests until the thing is compiled, you cannot compile the thing until three files have been generated, and one of those files is generated by a script somebody wrote in 2014 and nobody has opened since. Something has to look at that tangle, work out which steps can happen at the same time and which have to wait, and then not get it wrong, several thousand times a day, on somebody else’s laptop, silently.

“A rebuild you didn’t need is a minute you pay for twice,” Cowen said. “Once while you sit there waiting for it, and once because you gave up waiting and went and looked at something else, and now you have to come back and remember what you were doing. Nobody counts the second one. The second one is the expensive one.”

The ordering problem is trivial when a project has nine steps in it and vicious when it has nine hundred, and the awkward part is that no project ever notices itself crossing from one to the other. It simply gets slower, in the way a house gets colder, and everybody adapts.

“Disruption means somebody loses. Usually it’s whoever was maintaining the old thing for free.”

The forty-millisecond problem

The project began in August 2016 as three hundred and forty lines of Python, written on a Saturday at a kitchen table, because a friend of Cowen’s ran the nightly data pipeline for a small research group and was maintaining its running order by hand, in a comment at the top of a shell script. The pipeline rebuilt everything every morning whether or not anything had changed. It took a little over two hours, and about once a fortnight it was wrong in a way nobody caught until the afternoon.

What Cowen wrote for him was not, by any measure, exciting. It read the dependencies the group had already written down, worked out which steps genuinely had to run again, and proposed an order.

What made it work was not the algorithm. Cowen is dismissive of the algorithm to a degree that other people who work on schedulers find funny. What made it work, he says, is that it disappeared.

“Every build tool I had ever used announced itself,” he said. “Banners. Progress bars. A summary at the end telling me how clever it had just been. You are a stagehand. Nobody claps for the stagehand and nobody should. And if the deciding takes longer than the smallest piece of the actual work, you’re not scheduling anything, you’re in the way.”

He set himself a number and never published it: whatever else happened, the decision itself had to be over inside forty milliseconds on a slow machine. Forty is roughly the threshold at which a person stops experiencing a computer as instantaneous and starts experiencing it as a computer. Nine years and a hundred and forty-eight releases later, it is the only figure in the project he can quote from memory, and he quoted it twice.

That constraint hardened, over the following two years, into the single rule he applies to the whole thing, written in marker on an index card taped inside a kitchen cupboard door: nothing goes in if it needs a tutorial.

Being depended on by people who have never heard of you

He released it in March 2017, under a license he says he chose in about four minutes, with a readme that ran to a page and a half and has been edited eleven times since. Then nothing happened for five months.

What happened after that is the part he still describes as strange. plait did not become popular the way software becomes popular. Nobody wrote about it. It got picked up one project at a time by people building other tools, and then those tools got picked up, and it travelled in the bag. It is now, on the best estimate available, somewhere inside eleven thousand four hundred published projects, almost none of which mention it anywhere a user would look.

“The first time I saw it somewhere I hadn’t put it,” he said, “was a screenshot in a bug report for a completely different program. Somebody had pasted a stack trace, and about four lines down there were my function names. I had never heard of the program. I sat and looked at that for a long time.”

I asked what the feeling was. He thought about it and said it was closest to finding out that a chair you built is in a room you have never been in, and that somebody is sitting on it, and that if it broke they would be annoyed at the chair.

What the arrangement actually costs him is Tuesday nights. The issue tracker is open, the people filing in it are strangers, and they are strangers who are — fairly — irritated: a build that worked on Friday does not work on Monday, and the trace has his function names in it. He answers, by his own estimate, about ninety percent of them, in a register I have now read enough of to describe as relentlessly unbothered. There are one thousand four hundred and twelve closed issues. Two hundred and six people have contributed code. One person can merge it.

I asked whether he ever wants to walk away from it. He said “once a year, in about February,” and then, after a pause, that it passes, and that it is a Tuesday-night feeling rather than a life-sized one.

The offer he turned down

In September 2022, somebody tried to buy it.

The approach came by email, from a company Cowen will not name, and it was not a joke. They wanted the copyright, the name and the repository, plus him, for two years, on a salary that he describes as embarrassing to have been offered. The plan was stated plainly, he says, with no attempt to dress it up: leave the last open version where it was, and take the next one closed.

The number, in his words, was “a house and most of another house.”

He said no in a day.

“It did not land the way you’d think,” said Ellery Boothe-Nakagawa, who maintains a testing framework that has depended on Cowen’s scheduler since 2019, and whom Cowen telephoned that week, apparently mostly to say it out loud to somebody. “Once it got around, there were two theories. One was that he was holding out for a bigger number. The other was that he had some ideological thing about licenses and was going to write a manifesto about it. Neither was true, and it took people about a year to believe that. He had done arithmetic.”

What Cowen had actually done, according to him and to the two notebook pages he was willing to hold up but not hand over, was work out what the money was for.

“It buys time, a house, and not worrying,” he said. “I have the house. I bought it in 2016 and I am not moving. I have the time, because there is nobody above me putting things in my calendar — that’s the whole reason I never built anything around this. So it was for the not worrying. And I did the sum, and I already wasn’t.”

I pushed harder on this than on anything else in two days, because it is the one point where the modesty stops being a manner and becomes a decision with a price on it. Was there not a version where he took the money, gave most of it away, and wrote something else?

“There was, and I sat up most of a night with it,” he said. “The problem is that the thing they wanted only works because it’s open. Eleven thousand projects didn’t choose me. They chose something they could read, and fork, and fix at two in the morning without asking anybody. If I sell that, I am selling something that isn’t really mine.” He stopped, and then added the only sentence in two days that sounded rehearsed and which I do not believe was: “Also I’d have had to stop answering the issues. Somebody else would have answered them worse.”

When I asked whether he had ever regretted it, he looked at me for a moment as though I had asked whether he regretted the roof.

“I kept the job I’m good at,” he said. “Why would I regret that?”

He did not tell me the next part. A mutual acquaintance did, two days later, and Cowen confirmed it with visible reluctance and then declined to expand. For several years he has been putting small amounts of his own money into small software projects — four and five figures, never more, usually into the hands of one or two people who are already most of the way through building something and cannot afford another six months of it. There is no fund. There are no partners. He does not take a seat on anything, he frequently does not take equity, and there is no page anywhere listing what he has backed.

“It isn’t investing the way people mean it,” he said, when I made him say something. “It’s the crates. Somebody has decided a thing is worthless before anybody looked at it properly. Sometimes the thing is a person.”

§

The interview he keeps redirecting

Somewhere in the second afternoon I started keeping a tally, because it had stopped being an impression and become a pattern.

I asked what he was proudest of. He answered with a description of a change that cut start-up time on old hardware by a hundred and ninety milliseconds, conceded unprompted that this affects almost nobody, and then defended it for four minutes. I asked about the years in the garage; he told me about the failure modes of surface-mount capacitors. I asked, twice, about the 2024 pledge his family fund made to the Port Alden Youth Literacy Fund, and got, twice, a redirect to the tutoring coordinator who he says does the actual work, followed by her name, spelled, in case I wanted to call her.

By the end of the day the tally stood at fourteen. Fourteen questions about Brandon Cowen answered with a description of a system, an object, or another person. It is either the most disciplined humility I have encountered in nine years of writing about people who build things, or a very good defensive habit, and after two days in his company I am not certain the distinction survives contact with him. He is not performing modesty. He simply appears to find the machinery more interesting than the operator, and he has organized an entire working life around that preference.

The only moment the deflection failed was small. I asked what he would do if the project were finished — if somebody solved the problem properly and there was nothing left in the tracker. He said he would go and fix something else. I asked what. He said he had a list, and then he did not tell me what was on it, and grinned for the first time in two days.

§

We finished at the Blue Anchor Diner, on the harbour road, which Cowen bought derelict in 2021, spent three years restoring, and then handed to a community trust he does not sit on. It is a 1974 prefabricated diner and it is, at seven in the evening in January, completely full. The counter seats fourteen. Every stool was taken.

He did not mention that he had restored it. The waitress called him Brandon and did not make anything of him. He ordered coffee, black, and pie, and when the espresso machine behind the counter started making a noise he did not like, he stopped mid-sentence, listened to it for four full seconds, and then finished the sentence.

I asked him the last question there: what he wants the software to be, in ten years. He thought about it longer than he had thought about anything else all week.

“Boring,” he said. “I want it to be so boring that somebody who has been running it every day for eight years couldn’t tell you the name of it. That’s not modesty. That’s the specification. Roads, water, power — you only learn the brand when it fails. Nobody should ever have to learn mine.”

Outside, the neon in the diner window was doing the thing old neon does, buzzing very slightly, holding steady. He had left it that way on purpose. He told me so on the way out, and then he changed the subject.

Ines Kowalczyk writes about infrastructure, maintenance, and the software underneath other software for The Groundwork. This piece appears in Issue 41.