“Metaphor is a way to discuss something we don’t understand, in terms of something we know even less about”
The idea of a software factory comes and goes, the critique equally predictably focus on all the ways creating software is not like factory work. The short forms of the one common counter arguments are “the factory bit of software development is called compiling”, this focuses on the factory as a turning raw materials into shipable product as primarily a machining problem. This is usually then followed by “if anything software development is more like product development” this focuses on what most consider the creative part software hoping to thus absolve software from the rigor of manufacture and cast it in the light of mainly creative, exploratory, artful discovery.
Now I’ll be the first to admit I know very little about actual, real, manufacturing as done in the world today. This knowing nothingness that I will boldly claim to be sharing with most folks doing software development might actually be a asset, as long as we keep cognizant about the fact that we’re not to make any literal claims. It’s a defocusing advice where the assumption is that given that we defocus through this lens we won’t get to bogged down by the details we (think we) know about actual software development.
In this light I think the software factory might be more compelling as a metaphor than we commonly think. Modern “lean” manufacture strives for highly flexible lines, producing goods increasingly to order with high customization. Blending automation and human touch, what Toyota long has referred to as “autonomation”. In this light I posit we can consider any system we build, buy or integrate into our delivery as a machine. How inputs and outputs flow becomes analogous to the flow of materials between machines.
As makers of software we’re thus in the position to be both creating a line and small factory of our own to turn ideas and source code into solutions. But those solutions themselves often are then used by ourselves our others to dynamically reconfigure an ever changing set of factories.
The Software Factory thus is not about producing the exact same thing (but neither is manufacture at large) it’s about producing some things, with varying degrees of standardization whilst also improving existing and adding new machines to the floor.
Given this perspective I think there’s fertile ground for thinking in terms of things we can observe in our mental simple models of factories. We got machines of varying sizes needing maintenance due to the corrosive effects of the outside world. We know that the huge machines are both costly and often comparatively inflexible. This might be good or bad depending on how stable the need for them and the specialization they offer is. We can visualize the flow of parts throughout and see where we’re both introducing unnecessary variance or where later stages needs to always modify their inputs to make them fit the desired flows. We can see how shared capabilities might both speed up delivery and bog us down when changes are needed. We can discuss the different skillets required to create a bespoke prototypes and the high speed, high quality manufacture of mass customized things.
We’re factory builders, and assembly line workers, we’re product designers. We’re consumers and someones upstream.
The Software Factory model is wrong. I’m starting to think that it’s wrong enough to be useful.