in your own image

Part three of four in “into solution,” on what software does to a problem when you take the word literally. Each part stands alone.

Software is the only medium we have ever had in which dissolving a burden is cheap. A burden goes in, the task stops being anybody’s job, and the work still happens nightly in a process nobody watches.

Now the bill. It is not the one people expect, and it is not paid in money.

what goes into solution is not what you put in

Water does not dissolve salt as salt. It breaks the crystal into ions and wraps every one of them in a shell of water molecules. What is in solution has been taken apart along the lines the solvent could grip and reassembled in the solvent’s own terms. There is no step at which the salt goes in whole.

Software does this to every burden it touches. To dissolve a task, software must first render the task in its own terms: a schema, a sequence, a rule, a set of fields with types. James Scott’s word for this, writing about states rather than software, is legibility — the observation that an institution can only act on what it can see, so it reshapes the world into something it can see, and the reshaping is not preparation for the act, it is the act. His word for what gets lost is metis: the local, practical, unwritten knowledge that lives in the people doing the work and in nothing else. The forester measures the forest, plants it in rows, and the forest dies in a generation, because the part that kept it alive was never in the survey.

Three things follow, and every one of them shows up in real systems.

The solvation shell is the schema. Everything that enters software gets wrapped in a representation first, and the representation is what runs. Nobody automates a job; they automate a model of the job, and the gap between those two is where the next five years of complaints come from.

The essential complexity precipitates. Brooks’s 1986 distinction holds: accidental complexity dissolves beautifully, and essential complexity comes back out of solution as a solid. It is the config file nobody understands. The exception path with one branch per angry customer. The internal thread titled “edge case” with sixty replies.

And the insoluble is defined by the solvent, not by difficulty. Oil is not hard to dissolve in water; it is not the kind of thing water grips. Judgment, taste, care, the hard conversation with a person who is going to be upset — none of those are resisting software. They are non-polar. There is nothing for the solvent to hold onto.

If you cannot describe it, software cannot dissolve it, and pretending otherwise produces a precipitate — a solid lump of unhandled reality sitting at the bottom of the system, where someone will find it later.

Software sees the task through the schema, and it sees only what the schema admits.

in your own image

Everything in the last section is told from the solute’s side, where it reads as loss. Turn it around.

To render a burden in your own terms is to re-make the little world the burden lived in, and to re-make it in your own image. Not metaphorically. The new world has the describer’s shape because the describer’s shape was the only one available. Every field you chose to have, every state you decided the thing can be in, every event you thought worth recording — that is a cosmogony, and it took an afternoon.

Legibility and creation are one act with two witnesses. The forest sees a survey that killed it. The forester sees a world, and the world looks like them.

This is redesigning the environment with the lid off, and it explains why dissolving is so much more powerful than solving and so much harder to take back. You did not remove a task. You replaced the conditions under which the task made sense, and the replacement is a description that came out of one person’s head on one particular Tuesday. The first thing anyone does with a new world is name what is in it, and the names stick. Everything downstream — every report, every integration, every argument about what a “customer” is three years from now — has to go through the names.

Vico had the epistemology for this in 1710, arguing against Descartes: we fully know only what we have made, which is why we can have real knowledge of mathematics and history and only ever secondhand knowledge of nature. It sounds like a seminar point until you notice it is a daily experience in this line of work. Nobody understands a process until they have written it down as code, and the understanding and the re-creation are not two steps. They are one step, and it has a side effect: the process is now yours.

Which is the good news and the whole of the bad news.

The image goes both ways. Build a system to your shape and you will be built to its; a year in, the way you think about the work is the way the schema thinks about the work, because that is the only interface you still have to it. Ask anyone who has lived inside a ticketing system they designed. The makers come to resemble the made.

dissolving is one-way

Mixing is free. Unmixing is a desalination plant.

That asymmetry is not a quirk of chemistry — it is the direction of the arrow, and software inherits it exactly. Once a burden is dissolved, the knowledge of how to carry it by hand drains out of the building. The role that carried it is gone. The pipeline that trained people into that role is gone. The institutional memory that it was ever a job, that someone sat there and did it and had opinions about how, is gone inside of about two cycles of hiring.

Three mechanisms, all described decades ago by people who were not talking about software:

The skill does not move into a new person, it disperses into the system, and you cannot recover it from the people who used to hold it — they held the doing, and the doing is now a service.

The tool becomes the only way to do the thing, because the alternatives dissolved. Past a certain point there is no “or we could do it manually.” There is only an outage.

And every technical fix generates conditions that only another technical fix addresses. The solvent for a software burden is more software. The reaction is autocatalytic; it produces its own catalyst, which is why the backlog never empties no matter how much you dissolve.

Nobody un-adopts the spreadsheet. The ones who look back turn to salt.

None of this is an argument against dissolving. I dissolve things for a living and I would do all of it again. It is an argument for asking the question before the pour rather than after, because after is the one direction the reaction does not run.

Works cited without a link: Vico, De antiquissima Italorum sapientia (1710) · Brooks, “No Silver Bullet” (1986) · Scott, Seeing Like a State (1998). Figures still in copyright are paraphrased, not quoted.