The Two Industries We Pretend To Be

We say "ship" like it means something: "When are we shipping the new feature?".

But shipping implies a boat. A harbor. A package crossing an ocean to reach someone who opens it.

What actually happens when we "ship" a feature? The bits don't move. They were already there - on a server somewhere, waiting. We flip a switch. We change a configuration. Nobody receives a package.

The metaphor is no longer suitable in most deployment environments. But we've used it so long that it feels true.

We borrow a lot of our language from two older industries.

From construction: architect, blueprint, foundation, build. Some code is load-bearing. We lay groundwork. We have technical debt, as if we've mortgaged a building.

And from manufacturing: pipeline, throughput, bottleneck, container. We deploy. We measure velocity. We talk as if there's a production line somewhere, stamping out units.

Both industries are physical. Both make things you can touch. Both assume materials have weight and change costs money.

Software is of course none of this.

A building is constrained by gravity. It exists in a specific place. Changing a wall means jackhammers and permits. And at some point, a building is finished. You cut a ribbon. You move in. It's done.

Software has no gravity. Change is cheap. And there's no ribbon to cut - it's never finished.

A factory's value is in repetition. Design the shoe once, make it ten thousand times.

For software, copying costs nothing. The value is entirely in the original - the design, the thinking. We're running a factory where production is free and the prototype is the entire job.

So we use physical language for something that isn't physical. We use building words when nothing is being built. And production words when nothing is being produced.

The building metaphor says: plan first, then execute. The factory metaphor says: measure throughput, optimize the line.

Neither works. Software isn't a building. It isn't a product. It's something else entirely.

At the time of this writing, AI agents are reinventing what software engineering means as a discipline. Systems that can build entire projects autonomously. Code that writes itself. The field is being reshaped faster than anyone expected.

Which makes this a strange time to ask: What is this discipline, really?

Maybe the answer is to go back to those borrowed industries. Not because construction and manufacturing are perfect parallels - they're not. But there was a reason early software people reached for them. Something rhymed. Something was useful.

And those fields kept evolving. Manufacturing learned lean production, just-in-time, continuous improvement. Construction developed modular building, prefabrication, new ways to handle change.

Software borrowed their language decades ago and then stopped paying attention. Maybe now - with everything in flux - it's worth looking again. Not to copy their answers. But to see what they've learned since we last checked.