Software has Always Been a Factory
28 June 2026
But production will continue to be the assembly line and the CPUs the line workers.
I’ve spent many years trying to apply the thinking of Deming, Ohno, and Goldratt to building software.
One of the insights I have gained from thinking about this for the better part of two decades is in a software company there exists four systems:
- production
- development
- the deployment / release pipeline
- commercialization
Production
In a factory, you can actually walk out into production. It’s the factory floor where the line workers work.
Don't look with your eyes, look with your feet. Don't think with you head, think with your hands.
-Taichi Ohno
On an assembly line, you want to minimize waste. Wasted movements that increase the time to perform an operation. Wasted parts, whether due to a defect or because a part was produced that was not needed and it sits on the shelf in a warehouse.
The Goal teaches us about bottlenecks and theory of constraints. A system only has one bottleneck, and optimizing anything outside that bottleneck doesn’t improve the efficiency of the system as a whole, and often harms it.
In most production software systems, it is desirable for the database to be that bottleneck and to optimize around it. Adding indexes to speed up queries, changing data structures to make data easier to retrieve, minimizing the duration of transactions or eliminating unnecessary ones.
The ideal we should strive for in an assembly line, is single piece flow. We should avoid batching as much as possible unless it is to make our bottleneck more efficient, which is why our databases generally don’t default to linearizable.
In a factory, we strive to create an environment that allows line workers to produce identical parts throughout their entire shift. Deming’s control charts allow us to determine if a variation was a special cause or common cause and determine if it is a real signal or just random noise.
A special cause variation. For example, an untrained worker performing an operation incorrectly leading to an increase in defects can be addressed with additional training.
A common cause variation. For example, variable material widths as input into an operation causing defects, requires redesigning the system to ensure the input material meets the requirements.
Deming would say that the minority of problems are common causes that require solutions like retraining or fixing a machine the majority are special causes that require redesigning some portion of the system in some way.
In a software production system, our line workers, the CPUs that carry out operations are far more deterministic than us meat sacks. CPUs are able to carry out the same operation repeatedly with much lower tolerances and they do it without tiring, around the clock.
CPUs are the ideal assembly line worker.
Development
The development system in a factory figures out what to build and how to build those things via the assembly line.
What new machines are needed. How to make the current ones work. What training workers need to have. How the parts are designed to minimize the amount of material needed.
Put another way, how to minimize waste in production.
The development system is far more adhoc and collaborative than the production system. There isn’t a clear and obvious bottleneck like the database here.
There are many people with different kinds of expertise that have to reach a consensus on how the design of the production system should be changed.
The work is often arranged into projects.
We incorporate customer feedback. We architect around the constraints of our infrastructure. We consider how a project fits the company’s strategy, the vision, its mission and its values.
This is where software engineering takes place and it is fundamentally different than the production floor.
I believe that the bottleneck in the development system is developing and disseminating a shared mental model comprised of:
- the company’s goals
- the vision for how to achieve them
- how the different projects play a role
- the priorities of different projects and selecting the right projects
- how the projects can be accomplished within the constraints of our existing production system
- how much effort we should expend on this particular project / goal
- the litany of the hundreds or thousands of different domain specific decisions that have to be made, documented, and continually tested
It’s not writing the code and for the most part never has been.
In fact, a lot of code that gets written is waste. That’s the idea behind “shift left” to minimize that waste by identifying problems earlier in the process via architectural decision records (ADRs) and product requirements documents (PRDs).
It’s incredibly helpful for the person doing the work to be able to take a step back and see the bigger picture when making a decision without every decision needing to involve a bunch of other people. In an information system, this is akin to partitioning or sharding.
The Deployment / Release Pipeline
The ideal is single piece flow. Most small changes flow easily from development to production. Often, there can be near zero change management involved.
With software, depending on the domain and our customers, the amount of downtime expected is on the order of minutes or hours per year. But for a factory, a significant enough change may require production to shutdown for days or weeks or weeks at a time.
Feature flags give us control over when a change is released.
Customer support and customer success teams help us communicate the impact of these changes to customers and help train them on new workflows. They also help collect feedback from customers that serves as input to the development process.
The bottleneck here is change management for existing customers.
Commercialization
This system is sales and marketing. I know the least about this, so bear with me.
This system is beholden to external parties, so single piece flow is nearly impossible. There is a lot of task switching involved. Cold calls / emails. Launching marketing campaigns. Sales calls. Sales engineering, etc.
But fundamentally, it involves convincing a prospect that they could be doing something better, that it is worth solving, and that your product is the right solution for that problem.
Once a prospect agrees in theory, actually getting them to setup your product, put it through its paces, train their team on it and get them onboard, integrate it into their existing processes, and roll it out is a long process.
A well designed product greases the wheels here, but large organizations move incredibly slow and have a low risk tolerance for something new.
Feedback from these prospects also acts as inputs to the development system, although less refined than feedback from existing customers.
Just like in the deployment / release pipeline, the bottleneck here is change management, but for prospects.
I point out the bottlenecks in the various systems because optimizing around them can improve the system as a whole, but optimizing everything else can cause the system to become less efficient.
In my opinion, having these specific bottlenecks in the associated system is ideal, and if it is not the case, perhaps you should ask yourself why you have a different one. I’ve only seen a few software companies and they tend to have been small ones, so it’s also very possible I’m missing something at different scales!
But, as far as I can tell, AI tools have yet to target these bottlenecks.
That is why we haven’t seen a step change in the features offered by software products we use everyday or an influx of new software tools. And in many cases we’ve seen our existing tools become less reliable.
Goldratt said, “Technology can bring benefit, if and only if, it diminishes a limitation.”
And so far, the limitations diminished by AI have been largely at the margin.