The Hardest Problem in Computer Science Is Still Naming Things — And Your Postmortem Titles Prove It

Every engineering team has a values poster. Every engineering team also has a service called “data-service-v2.” One of these tells you the truth about the culture.

You know the joke. Two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. It’s funny because it’s three things, and because every engineer has lived it. But the joke trained us to think of naming as a technical annoyance — a friction point between writing code and shipping it, something you solve with a thesaurus and a team vote, then forget about.

I want to argue something different. The names your team chooses — for services, projects, architecture decisions, incident postmortems, refactoring initiatives, Slack channels — are the most honest cultural artifacts you produce. More honest than your values poster. More honest than your engineering handbook. More honest than that paragraph on your careers page about “engineering excellence.” Names encode decisions. They encode who was in the room when the decision was made. They encode what the team knew at the time, what it was afraid of, and what it was trying to avoid admitting. And bad names persist not because teams are lazy — they persist because renaming is politically expensive, because the person who chose the name has usually left, and because the name often encodes a decision that someone else made in a meeting you weren’t invited to.

If you want to diagnose a team’s culture, don’t read its style guide. Read its names.

§ 1 — The Service Called “Platform”

I once joined a team that had a service called “platform.” I asked what it did. Three engineers gave me three different answers. One said it was an API gateway. One said it was a data aggregation layer. One said it was “the thing that talks to the vendors.” The service was four years old, had twelve contributors in its git history — seven of whom had left the company — and had accumulated so many responsibilities that any attempt to describe it required the word “also” at least twice per sentence.

The name “platform” wasn’t a mistake. It was a fossil. At the time it was named, it probably was a platform — a thin layer abstracting away vendor integrations. But the name carried no constraints, and because it carried no constraints, it accumulated every responsibility no other service wanted to own. “Platform” is a name that means “whatever we need it to mean,” and that kind of name is a standing invitation to dump work into a service nobody has to think about until it breaks.

Generic names aren’t a naming problem. They’re a boundary problem. A service called “platform” or “core” or “common” or “utils” is a service with no edges, and a service with no edges grows until it becomes the place where engineering goes to die. The name doesn’t cause the dysfunction. It enables it. The name says: this thing has no specific purpose, so any purpose will do.

I’ve seen this pattern at every company I’ve worked at. The service called “gateway” that became a monolith. The service called “shared” that every team depended on and no team owned. The service called “legacy” that was newer than three services called “new-thing.” The names are diagnostic — they tell you that at some point, the team stopped being willing to draw boundaries, and the name was the first place that reluctance showed up.

§ 2 — Version Numbers That Erase History

Then there’s the version-number name. “data-service-v2.” “auth-rewrite.” “payments-v3.” These names are everywhere, and they share the same pathology: they tell you something came before, but they don’t tell you what changed, why it changed, or what the previous version got wrong.

“data-service-v2” answers the question “is this the new one?” and refuses to answer any other question. What was v1? Why did it need replacing? Is v2 a rewrite, a refactor, or a parallel implementation? Will v1 be decommissioned, or will it run alongside v2 for the next three years while everyone pretends that’s temporary? The name gives you nothing.

The version-number name is a symptom of a team that decided not to commit to a narrative. Naming something “v2” is a way of saying “we’re moving forward” without specifying what forward means. It’s the engineering equivalent of “new and improved” — technically informative, culturally useless. And these names persist because the moment you give something a specific name — “the event-sourced billing service” or “the synchronous payments gateway” — you’ve made a commitment about what it is and what it isn’t. Version numbers let you dodge that commitment.

I’ve watched teams build v3 of a service while v2 was still being built. I’ve watched teams maintain v1, v2, and v3 simultaneously, each with its own on-call rotation, because nobody could agree on which version was canonical. The version-number name doesn’t track progress. It tracks the accumulation of decisions nobody was willing to close out.

§ 3 — Incident Names That Minimize What Happened

This is where naming gets serious. If your service names are cultural artifacts, your incident names are cultural fingerprints.

I’ve seen postmortems titled “Minor API degradation on March 14” that described a four-hour outage affecting the entire checkout flow. I’ve seen incidents codenamed “wobbly Tuesday” that caused six-figure revenue loss. I’ve seen an incident called “the blip” that took down authentication for forty minutes and locked out every internal tool — including the incident management dashboard.

The names we give incidents aren’t neutral labels. They’re organizational signals about how seriously we’re taking what happened. A postmortem called “minor API degradation” tells every engineer who reads it — and every executive who skims it — that this wasn’t a big deal. The four-hour checkout outage is already being softened before the root cause analysis is written. The name is the first draft of the spin.

Google’s SRE book dedicates an entire chapter to postmortem culture, and its table of contents reads like a taxonomy of operational seriousness — “Managing Incidents,” “Postmortem Culture: Learning from Failure,” “Tracking Outages” — each one a named, structured practice with formal expectations. The Google SRE book’s treatment of incident documentation makes clear that postmortems are first-class engineering artifacts, not afterthoughts dashed off between pages. Mature engineering organizations treat the naming and documentation of incidents as a deliberate practice. Immature ones treat it as a creative writing exercise where the goal is making the incident sound smaller than it was.

The minimizing incident name is a trust problem wearing a naming problem’s clothes. Teams name incidents carefully when they’re afraid of consequences. They name incidents casually when they don’t want anyone outside the team to pay attention. They name incidents with cutesy codenames when they want to signal that this is an internal matter, not something the business needs to worry about. Every one of these naming choices tells you what the team is afraid of.

§ 4 — The ADR That Records the Decision But Not the Duress

Architecture Decision Records are supposed to be the antidote to tribal knowledge. They’re supposed to capture not just what was decided but why — what alternatives were considered, what tradeoffs were accepted, what constraints were in play. In practice, most ADRs I’ve read are post-hoc justifications written by the person who won the argument, and their titles reflect it.

“ADR-014: Adopt Kafka for Event Streaming” tells you what was decided. It does not tell you that the team owning the message queue was overruled, that the Kafka migration was driven by a VP who saw a conference talk, or that the team’s preferred option — RabbitMQ, already running in production — was dismissed without a technical evaluation. The ADR title is a clean summary of a dirty process.

The problem isn’t that ADRs are dishonest. The problem is that the naming convention — “ADR-NN: Decision” — encodes only the outcome. The title becomes the canonical reference, and once it’s referenced in three other documents and two Slack threads, it’s locked in. Nobody goes back and amends an ADR title to say “ADR-014: Adopt Kafka Because the VP Saw a Conference Talk and the Team Was Outvoted.” That would be honest. It would also be career-limiting.

So the ADR title becomes a small fiction. Not a lie, but a simplification that erases the political context in which the decision was made. And the next engineer who reads it thinks the decision was made for the reasons stated, because the title gives them no reason to suspect otherwise.

§ 5 — Who Gets to Name Things

Here’s the pattern I’ve seen at every company: the person who creates the thing gets to name it. The person who creates the thing is usually the person with the most context at the time of creation. The person with the most context is usually the person who’s been there longest, or the person with the most political capital, or the person who happened to be in the room when the Jira ticket was created.

This means naming isn’t a democratic process. It’s an exercise in power. The senior engineer who spins up a new service at 11 PM names it. The junior engineer who joins six months later has to live with that name, work with it, explain it to new hires, and pretend it makes sense.

I worked with a team once where every service was named after a Greek myth. Atlas. Prometheus. Icarus. Sisyphus. The engineer who named them was brilliant, had a humanities degree, and left after eighteen months. The remaining team spent the next two years explaining to new hires why the billing service was called Sisyphus. The answer, as far as anyone could reconstruct, was that the engineer thought billing was a repetitive, futile task. This was either a joke or a cry for help, and by the time I got there, nobody could remember which.

Names encode the values and context of the person who chose them. When that person leaves, the name becomes a question nobody can answer. This is why renaming is so hard — not because it’s technically difficult (it’s a find-and-replace), but because renaming is an act of saying “the person who named this was wrong, and I know better.” That’s a political statement, not a technical one. Most engineers don’t want to make it.

§ 6 — The Political Cost of Renaming

So bad names persist. They persist because the cost of renaming is paid by the person who proposes it, and the benefit is distributed across everyone who will ever interact with the name in the future. The proposer takes the political risk of offending the original namer (if they’re still around), the technical risk of updating every reference, and the social risk of being seen as someone who cares about “trivial” things like names instead of “real” things like features.

This is the same dynamic that keeps bad code alive. The cost of refactoring is concentrated; the benefit is distributed. The difference is that with code, we at least have language for talking about technical debt. We have sprints for it. We have metrics that make the cost of inaction visible. With naming, we don’t. There’s no Jira label for “this name is actively misleading every new hire.” There’s no dashboard showing the hours lost to confusion about what “platform” does.

The result is that names ossify. They become part of the team’s vocabulary without ever being validated. Engineers learn them the way you learn the quirks of a codebase — not because they make sense, but because they’re there, and questioning them takes more energy than accepting them. The name becomes load-bearing. You can’t remove it without shaking the structure, and nobody wants to be the person who shakes the structure.

The NIST Cybersecurity Framework demonstrates what happens when an organization treats naming and categorization as a first-class discipline. Its structured taxonomy of risk outcomes — Govern, Identify, Protect, Detect, Respond, Recover — represents deliberate, institutional investment in naming as a foundation for shared understanding. The contrast with engineering teams that name incidents “the blip” and services “platform” is not subtle. When a government standards body takes classification more seriously than your engineering organization does, your engineering organization has a naming problem — and a culture problem.

§ 7 — Practical Experiments: Auditing Your Team’s Names

So what do you do about it? You can’t rename everything. You shouldn’t try. But you can start treating naming as a first-class engineering decision rather than an afterthought dashed off between standup and lunch. Here are three experiments I’ve run on teams I’ve been part of, with varying degrees of success and one outright failure that taught me more than the successes.

Experiment 1: The New-Hire Naming Audit. Ask someone who joined in the last 90 days to list every service, project, and recurring meeting name they’ve encountered, and write down what they think each one means. Don’t correct them. Just collect the answers. The gap between what the name says and what the new hire thinks it means is your naming debt, made visible. I ran this once and discovered that three engineers thought “the bridge” was a data pipeline, a Slack channel, and a deployment process. It was all three. The name “bridge” had been reused for different things by different teams over three years, and nobody noticed because nobody new had ever been asked.

Experiment 2: The Postmortem Title Review. Before your next postmortem is published, have someone who wasn’t involved in the incident read the title and guess the severity. If they guess low, the title is doing work for you — specifically, the work of minimizing what happened. Rewrite the title until a stranger can accurately gauge the impact. This sounds trivial. It is not. The first time I tried this, the original title was “intermittent 5xx errors in the EU region.” The rewritten title was “Checkout unavailable for 47% of EU customers for 2.5 hours due to connection pool exhaustion.” The first title was written by the on-call engineer. The second was written by the engineer who had to explain the incident to the CFO. Both were accurate. Only one was honest.

Experiment 3: The Rename One Thing Challenge. Pick one service, one document, or one recurring meeting with a bad name. Rename it. Track every reference. Update every link. Write a one-paragraph note explaining the old name, the new name, and why the change was made. This is deliberately small. The point isn’t to fix all your names — it’s to prove that renaming is survivable, to establish that names can change, and to create a template for the next person who wants to try. The political cost of the first rename is the highest. Every subsequent rename is cheaper because the precedent exists.

If you want to go deeper, borrow naming discipline from adjacent fields. Editorial teams use structured naming conventions for manuscripts and campaigns — a book title generator that enforces structure can teach you something about why constraints produce better names than open-ended brainstorming sessions. The principle is the same: names that follow a pattern carry information. Names chosen freely carry whatever the namer was thinking about that day, which is usually lunch.

§ 8 — What Your Names Are Telling You

Here’s what I want you to take away. Your team’s names are not a cosmetic concern. They’re a diagnostic surface. They tell you where your team has stopped drawing boundaries (generic names), where it has stopped committing to narratives (version numbers), where it is minimizing failure (cutesy incident names), where it is hiding political decisions behind technical summaries (ADR titles), and where it has let the context of departed engineers calcify into permanent confusion (orphaned codenames).

Every name is a small decision, but the aggregate pattern tells you something your retros never will — because retros are performed for an audience, and names are chosen when nobody’s watching. Names are what your team does when it thinks nobody is keeping score.

So go look at your service catalog. Read your last ten postmortem titles. Open your ADR repository and read the titles without reading the bodies. Ask yourself: do these names tell me what I need to know? Do they carry context, or do they require it? And if they require context — if every name comes with a story that isn’t in the name — then your team has a documentation problem no style guide will fix. Because the problem was never the names. The problem was the meetings where the names were chosen, who was in those meetings, who wasn’t, and the fact that nobody has been willing to revisit those decisions since.

Naming is the hardest problem in computer science because it’s the one that requires the most honesty. You can solve cache invalidation with better infrastructure. You can fix off-by-one errors with tests. But you can only fix naming by being willing to say: this name is wrong, this name is misleading, this name was chosen by someone who is gone, and I’m going to change it. That’s not a technical decision. It’s an act of cultural maintenance. And it’s the act that distinguishes a team that manages its knowledge from a team that just accumulates it.