← naveed.io On record · Case file · 2026-07
§ Case file — 8 min

Seventeen years in the same problem

Everyone's arguing about which model is smarter. Almost nobody asks what you used it for. On concentrated experience — told through two god models, a deleted production database, and a pot of apology coffee in Ottawa.

Naveed Kakal From a recorded interview

The first thing nobody tells you about an industrial laundry is that it happens in three dimensions. You walk in expecting a bigger version of the machine in your basement and instead there is weather overhead — bags of linen zooming around on rails, shuttles ferrying compressed slabs of it back and forth, air blasts going off like the building is breathing. On the clean side there's the smell of hot pressed linen, which Naveed Kakal has spent twenty years failing to describe better than "that fresh linen feel." On the soil side there are hospital sheets and hotel bar towels that have been sitting out for a day, and the job of sorting them by hand. He's blunter about that one: you need, in his words, a gross-level tolerance that can just hang around. Some people quit the same day. Soil sort runs some of the highest turnover in the building.

Kakal has been writing the software that runs these buildings since August 2006 — first on a predecessor system, then on this one. The version-control record picks him up in March 2009 and hasn't stopped since: seventeen years of tape, roughly 9,700 commits across Subversion and git, from an event handler named after his boss (created and deleted three minutes apart) to last month. He is now Director of Software Development at Kannegiesser ETECH. This is what two decades inside one problem actually buys, in his telling.

Not a brain. Cels.

Ask him about the system — eVue, the plant-floor platform he's driven most of his career — and he'll correct your framing before you finish. You imagine an all-controlling brain. It isn't one. "It's a collection of capabilities that we've put a unifying experience around," he says, and reaches for an older image: watching how a cartoon used to be assembled, the stacked transparent cels each carrying one moving piece, composing into a scene. The craft isn't the brain; the craft is the composition — and keeping it composed across every installation, each one a different building with different machines and a different floor plan.

The data model underneath is honest about where it came from. The team grew out of a couple of Minnesota neighborhoods, and the jargon came with them, straight off the floor. The unit of truth in the database is the sling — the bag the linen rides in — lately formalized as a batch. "That's sort of the god-model-level anchor of how we think of laundry," he says. Two gods, in the end: the parcel, and the rail it hangs from. Everything else is commentary.

He considers the plainness a feature with teeth. The model "isn't architected to be obtuse — by being so abstract and correct all the time." Because the software speaks the floor's language, the people on the floor can tell when it's wrong, and — more important — can help it get right again.

When the picture lies

Because it will be wrong. Jams happen; humans err. Linen gets pulled mid-process. Someone reroutes by hand because a line is backed up. The physical plant and its digital picture drift, and an undetected drift compounds: everything upstream coded wrong, reroutable or not, and his favorite summary of the whole failure genre — "did the towels not get dried because they thought they were sheets?"

So the system grew two reflexes, both of them older than the buzzwords for them. First, workflows for reality winning: when a load is expected somewhere and never shows up, an alarm asks a human what actually happened — it ended up here, it never left, it's gone, I'll handle it. The software offers the options that can physically occur, rather than insisting on its own arithmetic. Second, a complete memory of human touches: every user action logged, so that when a deleted batch knocks a line off-by-one for two hours and burns half a shift in rework, someone can trace exactly where truth left the building. His commit log has been muttering about this for sixteen years — log what sling each bundle got matched to, make the tag event visible in user actions — less a feature than a habit.

Ottawa, 1 p.m.

His best story about state is the day he destroyed all of it. In 2012, on a call, mid-demo, he went to reset what he believed was his local environment. The terminal was remoted into a customer's plant — the biggest one in the portfolio, in Ottawa. The command dropped their production database while the plant was running. Every bag still hanging, every rail still moving, and the system that knew what any of it was — gone, at one in the afternoon.

What happened next is the part he actually tells the story for. The call went out within minutes: it was us, here's what happened. He was on a plane that night, and on the floor for morning startup. By the time he landed, the plant had mostly re-inventoried itself back to life — so what was left to repair wasn't technical. He stood in the executive wing and took the accounting of what it had cost. He brought the coffees. He absorbed the ribbing — thanks for coming out and not fixing it for us — and then spent a couple of days on site tuning their system to their liking, because showing up is a deliverable too.

The company's response is the detail engineers don't believe: nobody revoked his access. He can, to this day, connect to that system and run the same command. "It was a very Naveed issue, not an ETECH issue," he says — and the years of work already banked meant one catastrophic afternoon didn't outweigh them. The customer stayed. They upgraded that same plant's software and controls recently, and built a new plant with the company besides. He still has those guys' numbers; they still trade birthday messages. He came out of the worst day of his career owing them one, and has been quietly paying the debt in reporting favors ever since.

The ledger

He did leave once. From late 2014 to early 2017 he worked at Centro, in a well-run, properly democratic engineering org — sprints, agreements, review culture. He rates it honestly: great team, real growth. "I think I wrote a lot better software," he says, "but we solved a lot less problems per developer dollar spent." That sentence is the whole ledger of his career philosophy. Back at ETECH, the operating mode was what he cheerfully calls dictatorial before immediately redefining it: not my-way-or-the-highway, but a zone of control — the standing permission to make the call, build your own tools, and skip the meeting. The team were "real escape artists" about committed roadmaps, he admits, and in exchange got to be relentlessly reactive to the actual floor. What looks like indiscipline from the outside was a compounding education: what's worth building, where you'll get burned, how burns resolve.

The outsider's read on all this — one person with production access and no committee — is a governance nightmare, and he knows it. His answer is arithmetic: flatten the roles into one capable person and you don't just save salaries, you remove seams — the joints between specialists through which responsibility gets passed, softened, and lost. Fewer seams, fewer places for the obvious solution to die of incentive misalignment. Ottawa is his proof: the reason a dropped database became a fourteen-year customer relationship is that the person who broke it, the person who understood it, and the person with standing to apologize for it were the same person, on the same flight.

What the years are for

Which brings him to why he's putting any of this on the record. The discourse he reads is model-versus-model, benchmark-versus-benchmark. "What did you use it for, and how you're going to put it together, seems to get lost in the weeds," he says. His claim is that seventeen years concentrated in one industry's process is precisely the thing that transfers: it trains you to see whole systems — where the constraints live, what's worth building at all, which feature dies because it depends on a human input step nobody will actually perform. So you don't build it. Ship the part that survives contact with the floor.

The new tools haven't changed that instinct; they've industrialized it. These days he starts AI-assisted projects by laying down constraints — little handbooks, auto-updated, describing how each app is architected, readable by humans and machines alike. Telemetry gets sized to the flock: "not every app needs a whole Sentry. Sometimes you can just tail a log and watch it happen live" — and skip months of instrumentation on someone else's SaaS. The one-man army with a zone of control used to be a weird artifact of a Minnesota laundry company. He suspects it's about to be the standard shape of a software team.

Seventeen years ago, in his first week on the record, he committed the message "sorting is working?" The question mark was doing a lot of work. Last November he shipped four hundred and thirty-four commits in a month against the same sort, the same rails, the same two gods. Somewhere in there is the difference between experience and concentrated experience: the question mark is gone, and he knows exactly which bag is lying to him.

Method — researched from 19 years of commit history Interviewed & drafted by Claude Code, via an interview skill Naveed built Style: reported case file Fact-checked & edited by Naveed Kakal