Skip to content

Software Is Not Manufactured

Software development looks superficially like a manufacturing process: there is a thing to build, a team to build it, and a delivery date. The instinct is to manage it the way one would manage the production of any complex artifact: detailed specification, scheduled milestones, fixed-scope contracts, quality control at the end of the line.

This instinct is wrong, and it produces predictably bad outcomes when applied. Software is not a manufactured product. The difference is not cosmetic. It is structural, and it affects almost every decision an organization makes about how to build, fund, and operate software.

What Manufacturing Actually Optimizes For

A manufacturing process is designed to produce many identical units of a known thing, reliably, at low cost. Its core challenge is repeatability. Once the design is settled, the question becomes how to produce a million of them with the lowest defect rate and the lowest unit cost.

This requires a particular set of properties: a stable specification, standardized inputs, repeatable processes, predictable timelines, and quality control to catch deviations. Decades of management practice (Six Sigma, lean manufacturing, the Toyota Production System) have refined the discipline of running such systems. They work well, in domains where the underlying assumptions hold.

Software does not satisfy any of those assumptions. Each non-trivial software product is, in practical effect, a one-off. Even when teams reuse frameworks, libraries, patterns, and infrastructure, each product encodes a unique combination of business rules, workflows, user populations, regulatory contexts, and operational constraints. There is no second unit to produce.

What Software Actually Is

If software is not a manufactured product, what is it?

The closest accurate framing is that software is codified business knowledge, written down in a form that a machine can execute. Each line of code captures a decision about how some part of the world should be modeled, processed, or responded to. The codebase, taken as a whole, is the team's evolving understanding of the problem and its solution.1

This framing has several implications that the manufacturing analogy obscures:

  • Discovery is most of the work. Figuring out what the software should do is harder than typing the code that does it. Requirements are not handed down from on high; they are uncovered through investigation, iteration, and contact with reality.
  • Requirements improve as the team learns. A specification written before the team has built anything is a hypothesis. It will be wrong in places nobody can predict. Treating it as final freezes the team's understanding at its least informed moment.
  • The product is not finished at launch. Production is where the team finally gets to see what they have built do its job. Most of what the team will ever learn about the product happens after launch, not before.2
  • Maintenance is the dominant cost. The cost of writing the initial version is a small fraction of the cost of operating, maintaining, and evolving it over its useful life. Decisions made in the first version are paid for in the next ten years.3
  • Each codebase is its own context. Best practices that worked in one project do not necessarily work in another. The system that produced them was different.

None of these properties fit cleanly into a manufacturing model. Trying to fit them in produces the predictable failures: contracts that price the wrong thing, schedules that estimate the wrong work, quality programs that measure the wrong outputs.

What Goes Wrong When the Analogy Holds

When stakeholders, contracts, or processes assume a manufacturing model, predictable failure modes appear:

  • "Just tell us what you want and we'll build it." The framing treats requirements as known inputs to a known process. The team that operates this way is structurally unable to push back on requirements that are wrong, missing, or incoherent.
  • Fixed-price, fixed-scope contracts for novel work. A contract that fixes both price and scope on work nobody has done before is a contract that will end in dispute. Either scope expands and the vendor loses money, or scope is enforced and the customer gets the wrong product.
  • Quality control as inspection at the end. A QA phase appended after development is treated as the place where quality is added. In reality quality has to be designed in from the start; inspection at the end catches symptoms, not causes.4
  • Velocity metrics treated as production rates. Story points completed per sprint becomes the operational measure of the team. The team optimizes for the number, not for whether the work was worth doing.
  • "Maintenance" as a separate, cheaper category. Initial build is funded as the real work; maintenance is funded as the cheap aftermath. The team that built the system moves on; a smaller team inherits it; the inheritance accumulates problems faster than the smaller team can resolve them.

What This Looks Like in Practice

A few habits that follow from treating software as something other than manufacturing:

  • Budget for discovery as part of the work. Time spent understanding the problem is not overhead; it is the work that determines whether the rest of the project is worth doing.
  • Treat requirements as hypotheses, not contracts. The first version of the requirements is the team's current best guess. Plan for it to be revised as the team learns.
  • Optimize for the cost of change, not the cost of the initial build. Architecture, testing, and observability investments pay back in maintenance, which is where most of the lifetime cost lives.
  • Use small batches and frequent integration. The closer the team's working units are to "one decision at a time," the faster the team learns whether each decision was right.
  • Plan for the system to evolve. A successful product is a moving target. Practices, contracts, and team structures that assume otherwise will fight the team's actual work.

Common misconception

"Once we define the requirements, the team just needs to build them."

Requirements usually improve as the team and stakeholders learn more. A team that cannot revise the requirements as it learns is a team that ships a worse product than the one the customer would have wanted.

See also: Why This Guide Exists, There Is No Perfect Software, Exploring the Problem Space, Product Thinking vs Project Thinking, Estimates Are Forecasts, Total Cost of Ownership, Software Is Economics.

  1. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975; anniversary edition 1995), and especially the companion essay No Silver Bullet (1986). Brooks's argument that software complexity is essential rather than accidental (most software complexity reflects the genuine complexity of the problem domain and cannot be engineered away) is the cleanest articulation of why software resists the productivity gains that manufacturing has achieved. ↩

  2. See Launch Is the Beginning. ↩

  3. See Total Cost of Ownership. ↩

  4. See Quality Is Designed In. ↩