Part 1 · Reframing the Production Problem
Manufacturing as a Disciplined Lens
What can software learn from manufacturing without treating knowledge work as an assembly line?
The industrial claim that contained its own limit
In October 1968, computer scientists, researchers, and industry practitioners met in Garmisch, Germany, for a NATO conference on a problem that had acquired an alarming name: the software crisis. Computers were becoming more capable, but the programs required to use them were growing difficult to build, understand, and maintain. Schedules slipped. Costs rose. Reliability was uncertain. The conference helped establish software engineering as a field, but it also exposed a disagreement that has never disappeared. Was software production primarily an engineering problem, a management problem, a craft problem, or something else?
M. Douglas McIlroy offered one of the conference's most industrial-sounding proposals. He argued for software components produced systematically, available in families, catalogued, evaluated, and reused. The title of his contribution—“Mass Produced Software Components”—invited an assembly-line interpretation. Yet the argument itself contained a warning against that reading. Replicating a software prototype was already trivial. The harder problem was creating components worth reusing, describing their properties, choosing among alternatives, and sustaining confidence in how they behaved.
That distinction is more than historical detail. It captures both the attraction and the danger of manufacturing language in software. Manufacturing offers a vocabulary of flow, quality, constraints, standard work, reusable assets, traceability, and feedback. It asks leaders to see connected production conditions instead of isolated tasks. But its most visible imagery—assembly lines, identical units, repetitive motions, interchangeable labor, and deterministic output—can distort software work if transferred literally.
The distortion is tempting because it offers apparent certainty. If software development could be made to resemble the controlled repetition of a physical line, managers might expect predictable rates, stable units of work, comparable workers, and quality achieved by enforcing compliance with a prescribed sequence. Variation would look like failure. Discovery would look like poor planning. Judgment would look like inconsistency.
Software does not support those assumptions. A copy of a program can be reproduced at almost no marginal cost, but producing a useful change still requires understanding a problem, a context, an existing system, and the consequences of intervention. Much of the work is learning what should be built and what the current system will permit. Even apparently routine changes encounter dependencies, incomplete knowledge, and operational conditions that are not fully visible in advance.
The central question is therefore not whether software is manufacturing. It is narrower and more useful:
What can software learn from manufacturing without treating knowledge work as an assembly line?
The answer is that selected manufacturing principles can strengthen software production when three conditions hold. The original mechanism must be understood. The software adaptation must be explicit. The point at which the analogy stops must remain visible.
This chapter uses manufacturing as a disciplined lens, not a literal model. It does not yet define Software Manufacturing. That task belongs to the next chapter. Here the purpose is to establish what the lens can reveal, what evidence supports the transfer, and what must be refused.
The memory sentence is simple:
Transfer the mechanism, not the machinery.
From visible machinery to invisible rules
The popular history of manufacturing is often told through visible artifacts: powered machinery, moving assembly lines, standardized parts, large factories, and industrial robots. Those artifacts matter, but they can conceal the management ideas that made production systems work.
Early mass production reduced the cost of physical goods by coordinating specialized equipment, standardized designs, interchangeable parts, and repeated operations. The moving assembly line became its dominant symbol because it made flow visible. Work arrived at a station in a prescribed sequence. The product moved; the worker's task narrowed. Under suitable conditions, output increased and unit cost fell.
That system depended on a physical economic problem. Producing another unit required more material, machine time, labor, movement, and inspection. Consistency across repeated units was valuable. Variability threatened rate and fit. The factory therefore sought stable specifications and controlled execution.
Software has a different replication economy. Once a functioning software artifact exists, copying its bits is inexpensive. Distribution and operation still have costs, and running software at scale can require substantial infrastructure. But the act corresponding most closely to stamping another identical physical part is not the main economic problem. McIlroy saw this in 1968. The industrial opportunity lay in organizing the creation, qualification, selection, and evolution of software components—not in accelerating the copying of an already completed program.
Manufacturing itself also evolved beyond the simplest mass-production image. Toyota's production system is important here not because software teams should imitate an automobile plant, but because Toyota challenged the idea that efficiency meant keeping every machine and worker continuously occupied. Its official history describes two foundations: just-in-time, in which needed items arrive in the needed quantity at the needed time; and jidoka, in which abnormal conditions are surfaced and production can stop rather than passing defects forward. Toyota's account traces these practices through experimentation and adaptation rather than a single act of invention.
Independent analysis reinforces that interpretation. Steven Spear and H. Kent Bowen described the Toyota Production System less as a set of visible tools than as a disciplined system of rules. Work was specified; connections between people were direct; pathways were explicit; and improvement occurred through structured experiments close to the work. Their claim was not that Toyota eliminated variation. It was that the system made expected conditions and deviations observable so people could learn from them.
This changes what manufacturing can mean to software. The transferable object is not the conveyor belt. It is the reasoning beneath the production system: make work and connections visible; control the amount of unfinished work; reveal abnormal conditions early; create a baseline that can be challenged; preserve evidence; reuse qualified knowledge; and turn operating experience into improvement.
Even that interpretation requires care. A production arrangement is also a work arrangement. It distributes autonomy, skill, pace, attention, and authority. Classic socio-technical research showed that technical redesign can disrupt the social organization through which people coordinate and exercise judgment. Later comparison of automobile plants at NUMMI and Uddevalla argued that standardization and learning need not be opposites, but it remained a two-plant interpretive comparison, not universal proof that a particular production model improves worker experience.
Manufacturing therefore offers neither a neutral toolkit nor a guaranteed path to performance. It offers mechanisms embedded in social and technical conditions. Transfer begins by preserving that fact.
What can transfer
Seven principles are useful to software-production reasoning: flow, quality at source, constraint visibility, standard work, traceability, reusable assets, and feedback. They are related but not identical. Each corrects a different failure of project-by-project activity. None transfers without adaptation.
Flow: manage movement, not busyness
Chapter 2 showed how a delivery system can be busy everywhere while an outcome barely moves. Manufacturing's first contribution is to make that distinction difficult to ignore. A flow perspective follows work across the whole path from demand to usable result. It asks where work waits, accumulates, changes hands, returns for correction, or competes for constrained capability.
The principle is not “move every software task at a constant rate.” Software work varies too much for that. Nor is the goal to remove every pause; some waiting protects safety, enables independent challenge, or preserves options while uncertainty is resolved. The transferable mechanism is end-to-end visibility combined with control of unfinished work.
Operations research provides the underlying discipline. Little's Law relates average work in a stable system to average throughput and average time in that system. Heavy-traffic queueing analysis explains why waiting grows sharply when variable demand approaches variable service capacity. These results do not turn software into a factory line or provide a universal delivery formula. They do establish that a system cannot indefinitely add active work to fixed completion capacity without changing elapsed time or throughput.
In software, flow therefore means limiting commitments to what the production system can absorb, observing waiting as part of delivery time, and measuring the movement of outcomes rather than the utilization of isolated roles. The non-transfer boundary is equally important: units of software work are not identical, arrival and service patterns change, and completion cannot be inferred from task count alone.
Quality at source: shorten the distance to truth
Jidoka is often translated as “automation with a human touch,” but the transferable mechanism is more precise. An abnormal condition should become visible where it occurs, and the system should make it possible to contain the problem before it becomes embedded downstream. Toyota's historical account links this logic to looms that stopped when a thread broke, preventing continued production of flawed cloth.
Software cannot install a universal defect sensor. Correctness depends on intended behavior, context, data, security, accessibility, operability, and changing expectations. Many important defects are disagreements about what the system should do, not departures from a stable physical specification.
Yet the principle still transfers. Automated tests, static analysis, reproducible builds, peer review, security checks, observability, staged releases, and rapid user feedback can reduce the distance between a decision and evidence about its consequences. The purpose is not to automate every judgment. It is to make inexpensive, repeatable evidence available early enough that people can act before error travels.
Quality at source also requires authority. A warning that nobody can act on is not a control. Teams need a legitimate way to stop, correct, or escalate work when evidence contradicts an assumption. At the same time, “stop the line” cannot mean that any signal automatically halts an entire enterprise. The software adaptation must be proportionate to consequence and designed around containment, reversibility, and accountable judgment.
Constraint visibility: improve the system at its limiting condition
Production systems are limited by something: a machine, material, skill, approval, environment, interface, decision, or amount of demand. When the constraint is hidden, every part of the organization may optimize locally while the whole remains limited.
Software constraints are often mobile and informational. A database specialist may be scarce this month; next month the constraint may be an unresolved policy decision, a test environment, a supplier interface, or the cognitive load imposed by a fragile system. The constraint can move as work changes. It may also be a feedback constraint: the organization cannot learn fast enough because users, operational evidence, or decision makers arrive too late.
The transferable principle is to make the limiting condition explicit and protect the system from flooding it with more work. The literal transfer to reject is a permanent bottleneck label attached to a person or team. Such labeling can intensify dependence, overload the very capability the organization needs, and confuse a structural constraint with individual performance.
Standard work: create a baseline for learning
In a physical production setting, standard work can specify sequence, expected time, inventory, and safety conditions. In software, a fixed sequence cannot describe every discovery path. A novel architecture decision and a routine dependency update do not require the same reasoning. Attempts to prescribe all work can drive real decisions into informal channels while the official process becomes a compliance performance.
The transferable mechanism is a shared, visible baseline. Teams can agree how code is reviewed, how evidence is recorded, how changes are built, how operational risk is assessed, or how an incident is handed over. The baseline reduces needless reinvention and makes departures discussable. It is valuable precisely because it can be revised when evidence shows that it is wrong.
Spear and Bowen's analysis matters here: specification and experimentation were connected. An explicit expectation made a deviation visible; a structured experiment changed the system. Adler and Cole similarly argued that standardization at NUMMI could support organizational learning, although their comparison cannot establish that result across contexts or settle every labor concern.
Software standard work should therefore be owned near the work, versioned, open to challenge, and evaluated by its effect on outcomes and human burden. It should describe the safest known method for recurring conditions, not suppress judgment where the work is genuinely novel. When a standard cannot be questioned, it has stopped being a learning baseline and become administrative control.
Traceability: preserve the path from intent to consequence
Physical production uses lots, serial numbers, process records, and inspection evidence to reconstruct how an item was made and where it went. Software needs a different but related chain. A consequential change may connect intent, requirements, decisions, code, dependencies, tests, approvals, deployment, configuration, runtime behavior, and incident evidence.
The transferable mechanism is reconstructability. When something fails—or when an auditor, user, or operator asks why it behaves as it does—the organization should be able to find the relevant relationships without relying entirely on personal memory.
The boundary is proportionality. Recording everything forever creates cost, noise, privacy exposure, and surveillance risk. Traceability is not equivalent to document volume. The useful question is which evidence will be needed to make a named decision, demonstrate an obligation, contain harm, recover service, or learn. Chapter 15 will address this discipline in full. Here it is enough to establish that evidence is part of production, not an administrative residue after production ends.
Reusable assets: industrialize qualification, not copying
McIlroy's argument returns most directly in reuse. Software components can be copied without remanufacturing them, but useful reuse requires more than a repository. A consumer needs to know what an asset does, the conditions under which it is suitable, who maintains it, how it changes, what evidence supports it, and what happens when it is retired.
The manufacturing analogy helps by separating an engineered, qualified asset from an accidental fragment that happens to be copied. Interfaces, provenance, tests, documentation, support, compatibility, and ownership determine whether reuse reduces work or merely moves uncertainty to the consumer.
The non-transfer boundary is that software reuse is not free assembly from stable parts. Components interact through changing platforms, dependencies, data, and organizational assumptions. Adoption requires learning and integration. A shared asset can concentrate risk or impose a standard that fits its producer better than its users. Reuse compounds only when the asset remains fit, supported, and economically preferable to alternatives. Chapter 10 will develop that lifecycle; this chapter establishes why the industrial lesson is qualification, not replication.
Feedback: make experience change the system
A production system learns only when evidence from work changes future work. Feedback can come from a failed test, a user session, an incident, a queue, an exception, a successful reuse, or an unexpected operational pattern. The manufacturing contribution is to treat that learning as part of production rather than an optional retrospective activity.
Software makes this both easier and harder. Instrumentation can produce rapid, detailed evidence. Digital artifacts can be changed and redistributed quickly. But the volume of data can obscure the decision it is meant to inform. Measures can become targets. Teams can collect evidence that nobody owns or trust dashboards whose definitions are unstable.
The transferable mechanism is a closed learning loop: an explicit expectation, observable evidence, a responsible interpreter, authority to change the system, and a way to see whether the change helped. The boundary is that data does not interpret itself. Learning remains a social process involving judgment, disagreement, and context.
Where the analogy breaks
The seven principles are useful because they direct attention to production conditions. They become dangerous when their physical form is mistaken for their mechanism.
Replication is not development
Physical mass production solves the recurring problem of making another unit. Software reproduction solves that part almost automatically. Development is the work required to create, understand, adapt, and qualify the artifact before or between replications.
This changes the economic center of gravity. A production line that makes a million identical physical components spreads design and setup costs across costly repeated manufacture. A software service may also spread development cost across many users, but each additional copy does not require the same transformation of material. The continuing costs lie in operation, change, assurance, support, and adaptation to a changing environment.
Treating development as replication therefore rewards the wrong regularity. It may encourage managers to count features as equivalent units, compare teams by output volume, or demand stable rates from work whose uncertainty differs. The useful industrial question is not “How do we make developers produce more units?” It is “Which knowledge, evidence, assets, and conditions make valuable change easier to repeat?”
Discovery cannot be scheduled away
Frederick Brooks argued that software has essential difficulties rooted in complexity, conformity, changeability, and invisibility, alongside accidental difficulties created by tools and methods. Tools can reduce accidental work dramatically. Better languages, automation, platforms, and reusable assets matter. But removing avoidable friction does not remove the need to understand a complex problem or choose among interacting consequences.
Peter Naur gave the boundary a human form. He described programming as theory building: programmers develop an understanding of how a system relates to the world and why it has the form it does. The program text is an important artifact, but it does not fully contain that understanding. When people with the theory leave, successors can possess the code and still struggle to change it coherently.
The implication is not that software work must remain artisanal or undocumented. It is that codification has a limit. A procedure can preserve known checks; it cannot anticipate every situation in which those checks must be interpreted. Documentation can accelerate understanding; it cannot eliminate the learning required to build a working theory of a living system.
Discovery is therefore a production activity. It can be bounded, supported, made visible, and tested. It cannot be declared finished simply because a project plan requires certainty.
People are not interchangeable capacity
Assembly-line imagery encourages a view of workers as replaceable units assigned to standardized stations. Software knowledge makes that assumption especially costly. People hold relationships, history, tacit models, and situational judgment. Moving them is not equivalent to moving fungible capacity. Adding people can increase coordination work before it increases completion capacity.
The human boundary is broader than knowledge retention. Process design changes who can decide, who must wait, whose work becomes visible, who carries administrative burden, and who is held responsible for outcomes. Trist and Bamforth's socio-technical analysis remains relevant because technical efficiency cannot be assessed separately from the social system it creates.
Evidence from software process improvement makes the trade-off concrete. Lavallée and Robillard's systematic review covered 26 studies. It found reported benefits including improved communication and fewer crises in some settings, but also documentation and data-collection overhead, excessive focus on technical process, and tension when management prioritized process quality while developers prioritized product work. The result is not a verdict against process. It is evidence that process is an intervention in work, with effects that must be observed rather than assumed.
The evidence base does not justify universal transfer
Lean ideas have circulated in software for decades, but adoption is not proof. Pernstål, Feldt, and Gorschek screened 10,230 records in a systematic review and retained 38 studies relevant to lean approaches in large-scale software systems development. They reported a literature dominated by weak contextualization and nonempirical work, with limited practitioner support for some large-scale, cross-departmental concerns.
Those numbers describe the review process, not an effect size. They do not show that lean methods fail. They show that broad claims about their success exceed the evidence available in that review. Context, implementation, unit of analysis, and outcome definition matter.
This is a crucial boundary for executives. A named practice may have a credible mechanism and still fail in a particular organization. A positive case may show possibility without showing transferability. A method may improve flow while increasing burden elsewhere. Disciplined use of manufacturing ideas therefore requires local evidence and explicit non-claims.
The disciplined transfer test
The chapter's framework is a three-part test for any proposed transfer from manufacturing to software.
1. What is the original mechanism? Describe the causal or operational logic without relying on the visible artifact. For jidoka, the mechanism is rapid detection and containment of abnormal conditions, supported by authority to act. It is not the cord hanging above an automobile line. For standard work, the mechanism is an explicit baseline that makes deviation and improvement observable. It is not a universally fixed sequence.
2. What is the software adaptation? State what changes because software work is variable, knowledge-intensive, digitally replicated, and embedded in evolving systems. Quality at source may become automated checks plus peer judgment, staged exposure, observability, and rollback. Flow may become control of work in progress across idea, code, evidence, deployment, and operation.
3. Where does the analogy stop? Name the assumption that must not transfer. A test suite cannot establish every dimension of quality. A standard cannot replace discovery. A shared component does not remove integration cost. A person is not fungible capacity. A dashboard is not organizational learning.
These questions form a gate, not a scoring model. If the original mechanism is unclear, the proposal is imitation. If the adaptation is unclear, it is metaphor. If the stopping point is absent, it is ideology.
The test should also be applied in reverse. A practice should not be rejected merely because its physical expression looks alien to software. Stopping a line may sound impossible until the mechanism is reframed as containing a release, blocking a compromised dependency, or suspending a risky change. Standard work may sound anti-creative until it is applied to recurring assurance tasks that otherwise consume attention inconsistently. The discipline is to separate mechanism from form in both directions.
F03.1 — Principle transfer and boundary matrix
| Principle | Original mechanism | Useful software adaptation | Non-transfer boundary or misuse risk |
|---|---|---|---|
| Flow | Observe and control movement through the whole system | Limit unfinished work; include queues, evidence, and operation in elapsed time | Work items are not identical units; utilization is not flow |
| Quality at source | Detect and contain abnormal conditions near creation | Fast automated evidence, peer judgment, staged release, observability, rollback | Automation cannot define every dimension of correctness |
| Constraint visibility | Protect and improve the system at its limiting condition | Expose scarce expertise, decisions, environments, interfaces, and feedback delays | Do not label people as permanent bottlenecks or flood constraints |
| Standard work | Make the current best method explicit so deviation and improvement are visible | Versioned, challengeable baselines for recurring work and evidence | Do not prescribe discovery or convert standards into surveillance |
| Traceability | Reconstruct material, process, and inspection history | Connect intent, decisions, changes, evidence, release, and runtime consequence | More records are not automatically better; respect cost, privacy, and retention limits |
| Reusable assets | Qualify repeatable components and their interfaces | Governed components, templates, environments, knowledge, and controls with ownership | Copying is cheap; adoption, integration, support, and retirement are not |
| Feedback and learning | Use observed deviation and performance to change the production system | Decision-linked operational and production evidence with authority to improve | Data is not learning; measures can distort behavior |
The matrix is not a maturity model. An organization does not progress by maximizing every row. A safety-critical service and an internal experiment may need different controls. The table's purpose is to force each transfer claim to carry its boundary with it.
Two production systems, one learning problem
The disciplined transfer test becomes clearer through a paired case: Toyota and the NUMMI plant on the physical side, and NASA Goddard's Software Engineering Laboratory on the software side. The cases cannot be compared through a common productivity or defect measure. Their products, economics, work, periods, and institutions differ. The legitimate comparison is narrower: how did each make experience usable for improvement, and what conditions limited that mechanism?
Toyota's system connected explicit work with rapid problem visibility and local experimentation. Spear and Bowen observed that the apparent rigidity of detailed rules coexisted with structured improvement. A deviation did not merely indicate that a worker had failed to comply; under the system they described, it created information about the work or its conditions.
NUMMI, the joint venture between General Motors and Toyota in California, became an important site for interpreting that relationship. Adler and Cole contrasted NUMMI with Volvo's Uddevalla plant and argued that standardization could provide the shared baseline required for learning. Their account also makes clear why “copy Toyota” is not a sufficient instruction. Work design, worker involvement, training, authority, and institutional context shaped what the routines meant.
NASA's Software Engineering Laboratory addressed a related problem in a different medium. Established at Goddard Space Flight Center, the SEL brought together NASA, the University of Maryland, and a contractor organization. Its domain was flight-dynamics software. Over years of projects, it collected experience, established local baselines, evaluated methods, and fed what it learned into subsequent development. A 1992 account described fifteen years of operation and hundreds of studies and reports, ranging from controlled experiments to multi-project investigations.
The manufacturing principle was not a software assembly line. SEL did not make programming deterministic or replace engineers with a fixed process. Its transferable mechanism was institutionalized learning. Expectations were made explicit. Evidence was collected across real work. Practices were evaluated against a local baseline. Experience was packaged so that later projects could use it.
The case becomes more valuable because it includes decline, not only success. A 2002 retrospective by SEL leaders examined twenty-five years of process improvement and described both rise and fall. They emphasized that measures and models were grounded in a relatively homogeneous domain. Data collection required professional effort and careful interpretation. Improvement had to be integrated with development and owned by the organization.
As the environment changed, those conditions weakened. Funding was curtailed. The domain became more heterogeneous. Relationships and roles changed. Models that had been useful in one setting did not transfer automatically to another. Some project managers came to see data collection as overhead. The retrospective also reported the absence of a clear owner for the development process, leaving individual projects to choose their own structures.
This is failed-transfer evidence inside the case itself. The lesson is not that measurement systems inevitably collapse or that an Experience Factory should never be built. It is that the learning mechanism depended on context, ownership, credible measures, sustained resources, and a connection to the people doing the work. When those conditions changed, the visible practices could remain while their function weakened.
The paired case supports four conclusions.
First, explicit work can enable learning when it makes assumptions and deviations visible. It suppresses learning when compliance becomes the outcome.
Second, quality improves through short feedback and authority to act, not through inspection volume alone.
Third, experience becomes an organizational asset only when it is interpreted, maintained, and connected to future decisions. A database of lessons is not a learning system.
Fourth, transfer is local work. A practice that functions in one domain cannot be separated from its measures, skills, incentives, and ownership and expected to produce the same result elsewhere.
Toyota/NUMMI and NASA SEL do not prove a universal model. They demonstrate a disciplined way to compare production systems without pretending their outputs or people are equivalent.
What executives should ask
Executives do not need to choose between romanticizing craft and imposing an assembly line. They need to govern which parts of software production should become more explicit, repeatable, and evidence-rich, while protecting the discovery and judgment that cannot be standardized away.
Six questions make that balance concrete.
Which mechanism are we trying to transfer? If the answer is a tool, ceremony, board, role, or slogan, ask what behavior it is meant to change and why that change should improve the system.
What is different about our software context? Consider uncertainty, consequence, architecture, regulation, user vulnerability, operating model, workforce, and the condition of existing systems. Adaptation begins with difference, not resemblance.
Where must judgment remain? Name decisions that cannot safely be reduced to a rule, and give the responsible people enough information and authority to make them.
Who gains or loses autonomy, attention, and voice? A process that improves management visibility may create data-entry work, surveillance, or slower decisions for teams. Those are production effects, not adoption problems to be dismissed.
What evidence would show that the transfer is helping? Measures should connect to a decision and include burden and unintended effects. Activity, compliance, and tool adoption are weak substitutes for flow, quality, safety, learning, and user outcomes.
How can the standard change? Every recurring practice needs an owner, a review condition, and a path for challenge. Otherwise today's improvement becomes tomorrow's constraint.
The executive task is not to standardize everything. It is to distinguish recurring work that benefits from a reliable baseline, discovery work that needs options and feedback, and consequential work that requires independent evidence. The disciplined lens makes those differences governable.
What to remember
Six conclusions anchor the chapter.
-
Manufacturing is useful as a source of mechanisms, not imagery. Flow, quality at source, constraint visibility, standard work, traceability, reusable assets, and feedback can improve software-production reasoning.
-
Software's replication economy is different. Copying a finished artifact is cheap; creating, understanding, qualifying, operating, and changing it remain the difficult work.
-
Discovery and human theory are part of production. They can be supported and tested, but not eliminated through planning or codification.
-
Standardization is legitimate only when it preserves learning and agency. A useful standard is an explicit, revisable baseline, not a substitute for judgment or a mechanism of surveillance.
-
Evidence supports bounded transfer, not universal promises. Process-improvement studies report mixed effects, and lean-software research has important contextual and empirical limits.
-
Every transfer claim needs a stopping point. State the original mechanism, the software adaptation, and the assumption that must not cross the boundary.
The memory sentence is:
Transfer the mechanism, not the machinery.
From a disciplined lens to a category
The manufacturing lens has now done its limited job. It has made the production system visible without pretending that software is a physical assembly line. It has shown why flow, quality, assets, evidence, and learning belong in the same executive conversation—and why discovery, context, and human judgment must remain inside that conversation too.
What it has not done is define a management category. A lens can reveal a problem without specifying the object to be governed, its boundary, or its relationship to existing disciplines. Chapter 4 takes up that work. It asks what Software Manufacturing means on software's own terms, what it includes, and what it does not replace.