Solutions Over Problems: What IT Is For

Information technology does not create problems. It reveals them, and then it multiplies the number of people who can solve them.

What IT Actually Does

A tool reveals a problem by making a process visible. Before the tool, the process ran anyway. It was simply invisible. The spreadsheet did not create the accounting error. It made the error legible. The version control system did not create the merge conflict. It made the conflict visible before it shipped.

The second half is the multiplication. A tool that can be inspected and modified lets more people solve the problem it revealed. A tool that cannot be inspected concentrates the solution in the vendor. The problem is the same. The number of solvers is not.

The common claim is that technology creates more problems than it solves. This is true only when technology is treated as a closed system that accumulates dependencies without a corresponding increase in the user’s ability to inspect and modify the system. When technology is declarative, local-first, and under the control of the person who bears the cost, it does the opposite: it reduces idle overhead and expands the set of problems an individual can solve without external permission.

The Same Failure Mode

A long-running Windows installation and a long-running administrative state share the same failure mode. Both add processes more readily than they remove them. Both justify each addition as necessary coordination or protection. Both raise the baseline cost of simply existing inside the system. Both make subtraction exceptional. The user or citizen becomes a tenant of a configuration they did not write and cannot rebuild.

The parallel is exact enough to be useful. Windows is not bad because it has many features. It is bad in this comparison because the features arrive without a readable record and leave only through a difficult removal. The administrative state is not bad because it does things. It is bad in this comparison because it does things the same way.

The Declarative Method

Declarative systems reverse the direction. A NixOS configuration describes the desired state. A rebuild produces it. Prior generations remain available for rollback. Undeclared services do not run. The person who maintains the configuration can read every line that affects their machine. The same method applied to institutions would require every new agency, reporting regime, or compliance rule to be an explicit, visible addition that can be removed without a multi-year political campaign.

The method has three properties that matter here. It is readable before it runs. It is reproducible when it runs. It is reversible after it runs. Those three properties are what make the configuration belong to the person who maintains it.

The Real Distinction

The distinction is not sophistication. Closed, telemetry-heavy platforms can be extremely sophisticated. The distinction is whether the person who pays the cost retains the ability to read, modify, and rebuild the configuration that governs their tools, their data, and their attention. When that ability is preserved, technology facilitates solutions. When it is removed, technology multiplies problems.

Sophistication is orthogonal. A closed platform can be elegant, fast, and reliable. A declarative system can be rough. The question is not which one feels better. The question is who can change it when it is wrong, and whether the change requires permission.

The tool is not the variable. The configuration is.