You own a multi-million-dollar asset you have never met

Let's play a quick game. Imagine you've just bought a warehouse business. Big building, forty staff, trucks in and out all day, and the whole thing generates your entire income. Now imagine that on day one, your operations manager tells you the following:

"You can't come inside. Ever. Nobody can, really — not even me, not all of it. But it's going well in there. Trust me."

You would not accept this. You would not accept this for a warehouse, a restaurant, a dental practice, or a lemonade stand. The idea of owning a physical business you cannot physically enter is so absurd that no one has ever needed to write down a rule against it.

And yet if you run a software company, this is — precisely, structurally, unavoidably — your situation. The core asset of your business is a codebase. It is the machine that produces every dollar of your revenue. And you have never met it.

Wait, what do you mean "never met it"?

You've seen the product, sure. You've clicked the buttons. Maybe you've even scrolled through the repository once, the way a tourist scrolls past a cathedral. But seeing the product is not meeting the codebase, in the same way that eating at a restaurant is not inspecting its kitchen. The product is the dining room. The codebase is everything behind the swinging door, and the swinging door is locked to you in a very particular way: not by policy, but by medium.

A warehouse communicates its condition to anyone who walks through it. Cluttered aisles, a smell of something burning, a forklift with a suspicious wobble — the building broadcasts. It is made of atoms, and atoms are legible to owners.

A codebase broadcasts nothing. It is a few million characters of text that only compiles into meaning inside the heads of the people who work on it daily. The computer scientist Peter Naur made this point all the way back in 1985, in an essay called "Programming as Theory Building": the real program, he argued, is not the text at all — it is the theory of the program held in the developers' minds. The why of every decision, the map of what will break if you push where. The text is just the residue the theory leaves behind.

Read that again, because it's genuinely strange. The asset you own is not fully located in anything you own. A big chunk of it lives in the heads of your employees, and it walks out the door every evening at six.

The three questions that expose the whole thing

Here's a thought experiment. Don't ask your engineers these — just ask yourself, honestly, whether YOU could answer them about your own company's core asset:

1. What fraction of your codebase actually did any work yesterday? Not "exists." Not "compiles." Ran. Was called. Participated in producing revenue. Is it 90%? 50%? 20%? You don't know, and here's the uncomfortable kicker: in CodeNSM's own fleet telemetry, it is routine for a quarter or more of a production codebase's functions to be completely dormant at any given moment — present, maintained, and doing nothing.
2. Which ten functions would hurt the most if they broke at 2 p.m. on your biggest sales day? A warehouse owner knows exactly which loading dock matters. Do you know which functions are your loading dock?
3. What did your engineering payroll actually buy last quarter? Not in features shipped — in condition of the asset. Did the building get sturdier or shakier? Stripe's Developer Coefficient report estimated that developers spend more than 40% of their working week on maintenance and dealing with bad code. That means something like four out of every ten payroll dollars go into the part of the building you have never entered, doing work you cannot inspect, on problems you cannot see.

If you scored zero out of three, congratulations: you are completely normal. That's the problem.

"But I have great engineers I trust"

You probably do! This is not a trust problem, and framing it as one is exactly the mistake that keeps it unsolved. Your engineers are not hiding the warehouse from you. They can't show it to you, because they can't see all of it either. Each of them holds Naur's theory for their own neighborhood — the corner of the building where they work. Nobody, including your most senior person, holds the whole floor plan. (Ask a fifteen-person engineering team how the billing module from 2022 works, and watch everyone look at the person who left in 2024.)

And the building will not politely hold still while everyone's partial maps age. Meir Lehman formalized this in his laws of software evolution back in 1980: a program that is actually used must continually change, and as it changes, its complexity increases unless work is actively done to reduce it. Your warehouse rearranges its own shelving every single night. The maps in your engineers' heads are always, structurally, a little bit wrong — and the drift compounds.

How did we all agree to pretend this is fine?

Mostly by rebranding the blindness as a personality trait. "I'm not technical" is a sentence founders say with a self-deprecating shrug, the way someone might say "I'm bad with names." But notice what the sentence actually concedes: I have no independent knowledge of the condition of my company's primary asset, and I've decided that's a quirk.

Nobody says "I'm not financial" and skips reading the P&L. The finance function solved this exact problem centuries ago — owners can't personally count every transaction, so we built ledgers, statements, and audits: instruments that compress an unwalkable reality into a walkable page. The codebase never got its ledger. It got vibes, sprint demos, and a slide titled "Tech Debt" with three bullet points that were also on last quarter's slide.

To be fair to everyone involved, until recently the instruments genuinely didn't exist. You couldn't walk the warehouse because there was no walkway. That excuse is expiring — runtime telemetry can now report what every function in a codebase did today, in a form a non-engineer can read, which is roughly the moment the ledger was invented for code. (This is the thing CodeNSM was built to be, and that's the last I'll say about it here.)

The stranger in your cap table

Here's the framing I'd leave you with. Your codebase is not a document. It's not a pile of files. It is closer to a workforce — thousands of small workers, each with a job, each showing up (or not showing up) to production every day, some overworked, some asleep for years, a few quietly holding the entire company on their shoulders.

You would never say "I'm not really a people person" and decline to ever learn anything about your human employees. But the other workforce — the one that never sleeps, never quits, and does most of the actual work — is a stranger to you. You've never walked its floor. You couldn't pick its most important member out of a lineup.

The rest of this series is about what's actually down there in the dark: the dashboards that watch everything except the code, the dead weight still on payroll, the ten functions carrying your company that nobody can name. It's a strange building. It's YOUR strange building.

Time to walk it.