Why the Software Factory Analogy fails.

Software development is a domain of high change and instability.

There are studies that show that [ 1 , 2 ].

There are a lot of reasons for this fact:

Technically, software can easily and cheaply be changed.

Software systems are often very complex and therefore difficult to grasp at the first attempt.

New software often changes the way people work, so it changes the context in which it is growing. For further growth this new context has to be taken into consideration.

Technology is still changing so fast, that it is often not clear what is feasible at the time the a project will be done.

Software is meant to serve the business, not the other way round. When the business changes, software has to go along.

The point is, that in software development change is not an avoidable effect but lies at the core of the domain!

In the industry the domain of new product development has those characteristics of high change and instability.
The area of mass manufacturing on the other hand does explicitly not have these characteristics: It is predictable and has a low change rate. This makes it possible to get a stable specification and reliable plans near the start.

In my opinion concepts which are trying to bring the ideas of mass manufacturing to software development are not the way to go. Software Factories in the sense of the industrial revolution will never be possible. Even if you are able to ramp up an infrastructure that would technically allow mass manufacturing, you still cannot avoid dealing with change, which lies in the core of software development. Dealing with change does not fit into the process of mass manufacturing, it actually prevents it! [Remeber the armory scene in Jabberwocky?]

I think the analogy for an optimal process, a perfect toolchain and a mighty framework should not be the factory but rather the perfectly equipped laboratory: Everything you need for work is available, but doing the work is still a craft and a creative process!