Creating software is a time and labor-intensive activity comparable to the creation of physical goods. For that reason, many have likened a commercial software development organization to a sort of factory. In fact there are several books written on the topic of ‘Software Factory’. The main idea is that physical goods factories take in raw materials or components and convert them into finished products. Software factories take in requirements or change requests and convert them into finished software. This sort of reasoning persists in some of the Lean Software literature. In fact, in the early days we actually measured developer productivity in terms of lines of code per hour, as if they were assembling furniture.
The factory metaphor may be compelling. In regular factories, the materials go through transitions stages (the assembly line) including quality control and get released through some sort of optimized process (logistics). The analogies:
- Materials ⇒ change requests
- Manufacturing flaws ⇒ bugs, defects
- Manufacturing ⇒ Development process (e.g. Agile)
- Release ⇒ DevOps
However, making furniture and making software does have it’s differences. Treating developers as assembly line workers might seem as the wrong approach.
The question is: How far can we take the analogy?
There are two clear differences between a physical factory and software:
Variation of artifact size and arrival rate
The goal of a factory is to efficiently make the same artifact (piece of furniture, car model, bottle of beer, etc.) with as little variation as possible. Every line of code, user story, and program is not exactly like the others. Unlike physical factories, software factories do not have consistency of artifact. This explains why Six-Sigma (the original Deming version with control charts, etc.) does not apply to software. As pointed out by Donald Wheeler in Understanding Variation (SPC Press, 2000), consistency of artifact is essential to having what Deming defined as a ‘controllable process’). Note, the lack of consistency of artifact is addressed in detail by Don Reinertson’s The Principles of Product Development Flow: Second Generation Lean Product Development (Celertis Publishing, 2012).
Uncertainty of effort and scope due to novelty of the effort
In factories, the artifacts are completely understood. There is very little innovation in the factory process. The innovation happened in the design and product engineering stages. If your dev team is not dealing with simple, well-understood, change-requests, but building new features or a new application, then the factory analogy completely breaks down. Your team is doing innovation on a schedule. Your organization is now a hybrid of engineering, design, building prototypes and manufacturing. Going into these efforts, the team has incomplete information and understanding about what is to be done. In this case, the ability to deliver the final product when needed is far from certain.
Agile methods try to address lack of consistency by decomposing the requirements into user stories categorized by size in story points. The usual categories are Fibonacci’s (1,2,3,5,8,13…). The team strives to get to a steady velocity (story points/ sprint). They are essentially treating the n-point stories as similar artifacts. This has mixed success depending on the context of the organization.
For novel efforts (whether new software, new systems, hardware, …), progress is best measured by the increase in likelihood, and the decrease in uncertainty over time, of meeting stakeholder expectations.
Processing these probabilities takes modern estimation and AI tools. Until recently no systems existed at all that could achieve this processing. Today Aptage has created and delivered tools that enable this measurement and management for innovation and development projects.