The Software Factory

The software development process and a factory are commonly intertwined in analogy attempting to bring a physical component to the often intangible world of software development. The idea of executing a defined process to create a deliverable makes this comparison natural. Software requirements enter on one side, and after a defined set of steps, a complete package rolls off the line, ready to be used.

Routines and well-worn processes can serve as our own factories and help provide predictability in life and business. A defined set of steps produces a desired outcome, essential for providing structure in a chaotic environment. The world of software can also be chaotic at times so it makes sense to reach for certainty and predictability.

Unfortunately, the predictability of an operating factory doesn’t translate to the design and construction of the factory itself. This process can be fraught with uncertainty, delay, and escalating costs. It requires experience, effort, and creativity to build a factory or create a good routine. When we mix up the factory analogy, we overlook the significantly greater difficulty in designing and constructing the factory compared to its operation. The principle holds true for software as well.

“We realized that the true problem, the true difficulty, and where the greatest potential is – is building the machine that makes the machine. In other words, it’s building the factory. I’m really thinking of the factory like a product.” - Elon Musk

Every time we are working to build a piece of software we are engaging in this difficult task of building the machine that builds the machine. This process must withstand various pressures, react to a shifting environment, and roll with uncertainty. At the outset, we don’t even know what the product is going to look like in the end! We have a conception of what it could look like but it will inevitably change throughout the development process.

Through the experience of designing and building the factory, we learn more about what we are building and how it can be constructed. We understand better what we like about the solution to our problem and what we don’t like as much as we originally thought. These realizations create conflict with the step-by-step assembly line we often associate with software development. Our process should instead embrace new information and the rapidly changing world around us.

These conflicts born out of the factory analogy result in unrealistic expectations. Stakeholders believe they can simply send in requirements, resources, and funding in one side and wait a defined time frame for the finished product to come out the other side. The mindset needs to shift to one of involvement, experimentation, and iteration. By thinking of software development as an evolutionary process we can better understand that each development project is not the execution of an assembly line but a quest to build the machine that builds the machine.

Does this sound like your experience with software development projects? Reach out @EncodedInsight and let me know!