Software Is Modeling

"All models are wrong, but some are useful." — George Box

Programming isn't the hard part of software. Modeling is.

The Real Work

System design predates computers by millennia. People have been designing processes, workflows, and organizational structures for as long as there have been people. Computers are a recent addition. They're tools — well-suited to information problems, the way a lever is well-suited to applying force. Coding is the act of translating a design into a language a computer can understand. It's important, but it's not the core intellectual work.

Think of novelists. A novel is a collection of sentences. But writing sentences isn't enough to make a good novel. The story, the structure, the ideas — those are what matter. A good story transcends its medium. It can become a film, a game, a play. The sentences are just the encoding.

Software is the same. You can rewrite a system in a different programming language and it's still the same system. The value is in the model — the decisions about what the system does, how data flows, what rules govern behavior. The code is the translation.

AI coding assistants are proving this empirically. They're good at translation. Not at modeling.

What Is a Model?

A model is a cheaper, simpler version of something real. It lets you try ideas that would be impractical or too expensive to try at full scale.

Consider the egg drop — a classic engineering exercise. You build a container out of cheap materials to protect an egg from a fall. You're modeling a force reduction system. Cardboard and tape instead of steel and titanium. An egg instead of something you actually care about. The point isn't to build a production-grade solution. The point is to discover principles — what absorbs impact, what distributes force — that you can apply later at real scale with real stakes.

You can model the same problem in software. Simulate the 3D world and its physics. Run a thousand egg drops with different container designs in seconds. No materials, no cleanup, no new eggs. Software models can be even cheaper than physical ones.

The tradeoff is fidelity. The real world is complex and chaotic. Your simulation might not capture all the physics of the situation. Things that work in simulation might not work in reality. That's fine. Models aren't supposed to be perfect. They're supposed to be useful — to let you explore a problem space cheaply and gain insights you couldn't afford to get any other way.

The Unique Advantage of Software Models

Here's something unusual about software: the model often is the final product.

When a civil engineer builds a scale model of a bridge, they still have to build the real bridge. The model informs the design, but it doesn't replace construction. The model and the product are fundamentally different things.

In software, that gap can shrink to zero. Your model of a billing process — the rules, the data flows, the edge cases — becomes the billing system. You don't build a model and then separately build the real thing. You refine the model until it is the real thing. The cost to go from model to production can be negligible.

This is a remarkable property that most other engineering disciplines don't have. And it means the quality of your model matters even more, because there's no separate construction phase to catch mistakes. What you model is what you ship.

Precision and Accuracy

Two properties separate good models from bad ones.

Precision is granularity — does the model distinguish between things that are meaningfully different? Say you're modeling a billing system. Some customers are tax-exempt. Some get volume discounts. Some are in jurisdictions with different tax rates. A precise model captures those distinctions. An imprecise model lumps them together — maybe it treats all customers the same, or all tax rates as one flat number. The imprecise model might work fine for simple cases, but it can't represent the real differences that matter to the business. Precision is about whether the model has enough resolution to see the problem clearly.

Accuracy is correctness. Given the distinctions the model does make, does it compute the right results? If the model knows a customer is tax-exempt, does it actually zero out the tax? If it knows the jurisdiction rate is 8.25%, does it apply that number correctly?

You can have one without the other. A model that distinguishes every customer type but calculates the wrong totals is precise but not accurate. A model that gets the math right for the one customer type it recognizes but misses all the others is accurate but not precise. You want both — enough resolution to see the relevant differences, and correct behavior for each one.

Model the Problem, Not the Solution

There's a subtle mistake that's easy to make: jumping straight to modeling the solution instead of modeling the problem.

When you model the problem — the business process, the rules, the constraints — you create something you can evaluate many solutions against. You define what success looks like. You establish inputs, outputs, flows, and measurements of performance. Then you can compare approaches and make informed trade-offs.

When you model the solution first, you've already committed to an approach before you understand the problem well enough to know if it's a good one. You skip the exploration that modeling is supposed to enable.

Not everything should end up as code, either. Automation has a cost. Sometimes a manual process is the right answer. Sometimes the best model reveals that the problem isn't worth solving with software at all. A good model is indifferent to whether the agent executing it is a computer or a person. It just models the process.

The Implication

If software is fundamentally a modeling activity, then the skills that matter most aren't language-specific syntax or framework knowledge. They're the ability to understand a problem domain, identify the right abstractions, and build models that are precise, accurate, and useful.

AI coding assistants make this impossible to ignore. These tools are remarkably good at translation — given a well-reasoned model, turning it into working code is increasingly mechanical. But they can't do the modeling work. They can't tell you which customer distinctions matter, what edge cases your billing rules need to handle, or whether you've identified the right abstractions. Give one a fuzzy model and it produces a precise rendering of bad thinking. The bottleneck hasn't moved. It was always at the modeling step.

Getting better at software means getting better at modeling. Everything else is translation.