Implicit State Is the Most Expensive Dependency

Some systems appear considerably more complete than they really are.

Everything works. Deployments happen. Customers get answers. Problems are resolved. Someone knows which configuration value matters, which procedure has an undocumented extra step and why the strange-looking piece of code nobody likes can't quite be removed yet.

Then that person goes on vacation.

Nothing necessarily crashes. Instead, ordinary questions become unexpectedly difficult. Why was this value chosen? Which version was actually approved? Is that workaround still necessary? Did we decide to replace this service, or did we merely discuss replacing it? Someone eventually reconstructs the answer from an old email thread, a commit message, a Slack conversation and the memory of another person who was in the room three years ago.

The system had state. We just hadn't noticed where some of it was stored.

Small organizations can operate this way for a surprisingly long time because people are extraordinarily good at filling gaps. Decisions happen in conversation, context travels through relationships and someone who has seen the same problem before recognizes it immediately. Formalizing all of that would take time, and when the same few people remain involved every day, the return may not seem worth the effort.

Sometimes it isn't.

Not every conversation needs minutes. Not every judgment needs to become a rule. If two people are working together for an afternoon, stopping every ten minutes to preserve their shared context for a hypothetical future employee would probably make the work worse rather than better.

Implicit knowledge isn't automatically technical debt.

The question changes when continuity begins to depend on it.

I've encountered old software that contained behavior nobody could explain until someone remembered a customer requirement from fifteen years earlier. I've seen processes with steps that looked unnecessary until we recovered the failure those steps were preventing. I've also seen procedures everyone followed because somebody once said they were necessary, long after the original reason had disappeared.

Those situations look similar from the outside. Something exists, the explanation is missing, and changing it feels dangerous.

That's when memory becomes an architectural concern.

Human memory is remarkably useful for carrying context, but it doesn't preserve information the way a database does. We compress experience. Details disappear. Later events change how earlier ones are remembered. Several conversations become one general impression of what “we decided,” and sometimes two people leave the same meeting carrying different versions of the decision.

That isn't a defect in people. Exact archival storage isn't what human memory is for.

Problems begin when a process quietly requires it anyway.

The obvious response is documentation, although documentation alone doesn't solve much if nobody knows whether it still describes the system. A beautifully written procedure from four years ago can be more dangerous than no procedure at all if everyone assumes it remains authoritative after the implementation has changed.

So the useful question isn't simply whether information has been written down. It's whether the information needed to operate, change and recover the system has somewhere durable to live and some way to remain connected to what actually happens.

Sometimes the software itself is the best place.

A deployment step that must always occur can become part of the deployment process. A configuration value can live in version control instead of someone's notes. A schema migration can record a transition that would otherwise have to be remembered. Tests can preserve the knowledge that a particular behavior matters without requiring the next engineer to know which production failure originally taught us that lesson.

Other knowledge belongs somewhere else. An architectural decision may need a short explanation of the alternatives considered and why one was chosen. An unusual operational procedure may need the history that explains why it exists. A customer relationship may contain context that would be absurd to encode into application logic but dangerous to leave entirely in one employee's head.

Different kinds of memory need different homes.

This is also why I wouldn't try to make the system remember everything. More recorded state can create its own reconstruction problem. Logs become enormous. Documentation multiplies. Decision records contradict one another. Nobody knows which artifact is authoritative, so people return to asking the person who remembers.

We've preserved the information and still failed to preserve understanding.

The goal is not maximum memory.

It's enough memory to continue.

One useful test is to imagine that the person who knows a particular thing becomes unavailable tomorrow. Not forever, necessarily. Give them a two-week vacation somewhere without cell service.

What becomes difficult?

If the answer is nothing, perhaps the knowledge was never an important dependency.

If someone needs to ask where a file is, that may be mildly annoying and worth fixing whenever convenient.

If nobody can deploy production, restore a database, understand a billing rule or determine whether changing a piece of software will violate an important requirement, we've learned something much more significant.

The person wasn't merely doing the work.

Part of the operating model existed only through their continued presence.

That can happen gradually because human compensation hides missing structure remarkably well. Someone notices the same error every Friday and corrects it. Another person manually reconciles two systems that don't quite agree. An engineer remembers to restart a service in a particular order. The organization experiences a functioning process while the person experiences a recurring interruption.

Eventually the workaround becomes normal enough that nobody recognizes it as a workaround.

Automation can help, but automating a poorly understood process can preserve the wrong thing very efficiently. Before turning someone's repeated intervention into code, I want to know what judgment they're applying. Are they performing a mechanical step the software should handle, or are they noticing differences among situations that our proposed automation doesn't represent?

Sometimes the human is compensating for missing machinery.

Sometimes the human is where necessary judgment lives.

Those aren't the same problem.

The distinction becomes especially important as an organization grows. A handful of people can maintain a surprisingly rich shared context through ordinary interaction. Add more people, more systems and more time between decisions, and the probability that everyone shares the same unstated assumptions begins to fall.

At that point, making important state explicit can reduce the amount of reconstruction everyone has to perform. The benefit isn't that the system has become more disciplined. It's that people can spend less attention repeatedly recovering information that could have survived without them.

That's the cost I care about.

If every unusual event requires finding Alice because Alice remembers why the system behaves that way, Alice has become part of the dependency graph. That may be acceptable for a while. Early systems often develop faster precisely because a few people carry enormous amounts of context and can change direction without formalizing every decision.

The arrangement becomes dangerous when everyone forgets that this is what makes the system work.

Then Alice leaves.

What follows looks like sudden complexity, but most of the complexity was already there. Alice had been compressing it.

The work now is not to extract everything Alice knows and convert it into rules. Some of what she knows will be obsolete. Some will be personal technique. Some will be judgment that another experienced person should develop differently.

We need to discover which parts the organization cannot afford to lose.

Maybe that's a recovery procedure.

Maybe it's why an apparently unnecessary constraint exists.

Maybe it's which record is authoritative when two systems disagree.

Maybe it's simply knowing that a particular question has never actually been settled.

Once those things have somewhere durable to live, people are free to carry the parts humans are better at carrying: judgment, interpretation, experience and the ability to notice that the documented answer no longer fits the situation.

That's a healthier division of memory.

The system doesn't need to know everything its people know.

It should know enough that nobody has to remain available merely so everyone else can remember how to continue.