Software Is Not a Factory

Or at least, the interesting part isn’t

A lot of people have been talking about Software Factories - Dark ones, Light ones...hell, I’ve been talking about software factories too.

I’ve even been building little versions of them myself. Task goes in. Something reads it, something designs, something implements, something reviews, something tests, something deploys. Add a board in front of it and a few agents in the middle and, well..you get a Factory.

And it’s an appealing idea, especially now: code generation got ridiculously fast. We can parallelize implementation. We can have specialized agents reviewing other agents. We can run tests automatically, deploy automatically, watch production automatically, feed incidents back into the system automatically.

The conveyor belt is almost visible and it’s so tempting because we’ll build it once and see it produce results while we watch it, or drink coffee, or sleep.

And because I like automating things, obviously my immediate reaction is: HOW FAR CAN WE TAKE THIS? Can it really do things without me? Without oversight?

But lately something about the factory analogy has been bothering me.

Because what exactly are we producing here? And what IS a Factory?..

Factories are very good at producing things we already understand

Imagine a factory producing chairs.

Before we start optimizing production, we have already made a rather important decision: we know we want chairs and we know, with some tolerances, what a chair is supposed to look like. We know which pieces go into it. We can measure whether the pieces are correct. We can improve how quickly those pieces move between stations. We can reduce defects. We can find bottlenecks.

Obviously real manufacturing is enormously more complicated than that, but the basic relationship still holds: You know what you’re trying to produce, and then you optimize how to produce it.

Software is weird because a surprisingly large amount of the time building is how we find out what we’re trying to build.

We implement a feature to see whether users actually want it, integrate with some system but the documentation says one thing and reality will inevitably say something slightly different, we build version A, look at it(or better give it to users) and go “nah, that’s not it.”

Sometimes the output of development is software.

Sometimes the output is simply: okay, now we understand the problem better.

And if that’s the case, treating every iteration as an inefficient attempt at producing the final product misses what the iteration was FOR.

Which makes “waste” a funny concept

Factories hate unnecessary variation: Standardize the components, the process. Reduce unnecessary movement and defects. Make the output predictable.

And a lot of software development should absolutely work this way too.

Do I want every developer inventing their own way of deploying something? - God no.

Do I want us spending three hours manually doing something that happens every week and follows exactly the same steps? - No.

Do I want an engineer lovingly hand-writing the 47th basically-identical configuration file because software development is a craft?

Please don’t.

Software has one horrifying property chairs don’t

The chair leaving the chair factory does not normally turn around, walk back inside and attach itself to the assembly line. Software does. Every piece of code we produce becomes part of the system against which the next piece of code has to be produced.

At first the obvious bottleneck is writing code - so you automated more of the implementation. Then suddenly you don’t have time to review everything properly. Then you can automate more of the review. Great. Now maybe the bottleneck becomes deciding what deserves to be built in the first place. “Taste is what matters”. You can keep chasing the bottleneck around the system forever. Which, to be fair, is basically my hobby…

But if in a normal factory, producing faster than the next station can handle gives you inventory piling up between stations, in software the excess output doesn’t just wait in a warehouse. It increases the environment’s complexity.

You add a service. Great, now every future change potentially needs to take that service into account.

You add an abstraction, maybe it makes the next ten changes easier. Maybe it makes them harder. We’ll find out.

You add another dependency, another API, another configuration option, another agent, another repository, another database, another clever framework that’s going to “simplify everything”.

All of those become part of the world the next developer - human or agent - had to understand. The next change has more code to search, more behavior to reason about, more interactions to consider, more tests to run, more things that can be affected. Which means the factory isn’t really a factory anymore…It’s some horrible self-modifying factory where every object coming off the conveyor belt gets bolted somewhere onto the machinery.

So I’m starting to think that one of the dangerous assumptions behind the “software factory” idea is:

more code produced = more software produced

I don’t think that’s true.

MORE DOESN’T MEAN BETTER

We know this intellectually. Every experienced engineer has looked at a PR deleting 4,000 lines of code and thought: beautiful.

Nobody wishes the system had MORE dependencies. Nobody enters a ten-year-old codebase and thinks: if only these people had implemented twice as many features.

And yet a huge amount of the excitement around agentic development is currently about increasing the rate at which we can produce changes.

More parallel agents, more tasks completed, more PRs…

But every one of those changes is a hypothesis about the system. And every accepted change alters the system the next agent has to reason about.

Which makes me wonder if code-generation throughput is actually a somewhat dangerous thing to optimize. Because the thing being generated participates in the context required to generate the next thing.

AUTOMATE WHAT’S BORING

I don’t think we should throw the factory idea away completely. I just think we need to be much more careful about where we draw the factory walls. Repeatable things, known transformation, things we’ve learned enough about that doing them manually no longer gives us useful information. I can’t believe this needs to be said, but:

Automate what has become boring

And I don’t mean emotionally boring. Because that’s the tempting part to automate (like I tried to automate choosing a ‘smiling, but not too much’ frame from a 1,5hour recording of a podcast). I mean boring in the information sense.

We understand it, we’ve done it enough times, the inputs are known enough and even the expected output is known enough.

Another one is “is doing this going to teach me anything?”. Not in terms of skills, cause that’s also tempting (let’s rollout Kubernetes, cause my CV needs that). But in terms of - will implementing this help me understand my product, architecture, tradeoffs, next steps - better? Will not knowing how it was built, prevent me from debugging it at 3AM? If the answer is YES - DO NOT AUTOMATE THAT.

The opposite is where I want my factory:

Build environments. Run tests. Deploy. Update dependencies when the risk is understood. Generate known boilerplate. Collect context. Check known constraints. Fine, even implement features when it comes to parts that are known, proven to work and it’s just about adding another brick. Do all the repetitive mechanical crap around development that humans have spent decades complaining about.

Please, factory the shit out of that.

But the other part? The part where we’re still asking should this exist?, why did this happen?, what does this system actually do?, what are we missing?, is A better than B?...I’m not sure increasing production speed helps there at all. In fact, it might make it worse. No, it WILL make it worse.