For nearly sixty years, a seductive dream has haunted the executive suites of the technology industry. It usually starts when someone in leadership looks at a room full of eccentric, expensive software developers, looks at a manufacturing assembly line, and asks a deceptively simple question: Why can’t we just build software the way Ford builds cars?
It is an intoxicating fantasy. Henry Ford took the chaotic, artisan world of carriage-making and replaced it with a synchronized ribbon of steel where a Model T rolled off the line every ninety-three minutes. Why shouldn’t software work the same way? Imagine an intake hopper where business requirements drop in, move down an automated line of interchangeable workers, and emerge out the other side as shiny, defect-free, predictable software on a fixed schedule and a fixed budget.
The trouble is that software has spent the last six decades proving that it is not an assembly line. Every time management orders software to act like a factory, the same collision occurs between the tidy world of manufacturing and the messy reality of human discovery.
Now, with the rise of autonomous AI coding agents, that sixty-year-old dream is back with a vengeance. We are being told that the final bottleneck, the messy human typing the code, has finally been eliminated. But before we surrender our tools to the new assembly line, we need to understand how we got here, why the factory promise keeps failing, and what earlier generations of engineers learned to value as they survived it.
This is the Past in a three-part series on software’s recurring factory ambition. The Present explores what today’s AI software factories are actually building, while the Future asks what people should get back if machines do more of the coding. The series title, Software’s Groundhog Day, is not just a joke about recurrence; it is a question about whether we are finally ready to learn the lesson. A lot of that lesson, it turns out, is not about tools at all.
The Garmisch Dream and the Component Fantasy#
The dream started with a crisis. In October 1968, fifty of the world’s top computer scientists gathered in the Bavarian resort town of Garmisch for the historic NATO Software Engineering Conference. Systems were blowing past deadlines, crashing in production, and devouring corporate fortunes. The phrase “software crisis” was coined in those rooms, and the attendees deliberately reached for industrial language: design, production, distribution, and service. The conference record reads like a field trying to invent a profession in real time.
At Garmisch, Bell Labs researcher M. Douglas McIlroy stood up and delivered a visionary pitch titled “Mass Produced Software Components.” He asked why software routines were still handcrafted from scratch every single time. Why couldn’t the industry have a Sears Roebuck catalog of standard subroutines? You could order components with known precision, robustness, and performance characteristics, snap them into place, and build complex applications in days. McIlroy’s paper wasn’t an executive blueprint to turn programmers into assembly line cogs; it was an engineer’s plea to stop wasting human lives rewriting basic mathematical routines.
Over the following decades, corporate leaders tried repeatedly to turn McIlroy’s component dream into literal factories. In the 1970s and 1980s, companies like System Development Corporation and Japanese giants like Hitachi, Toshiba, and NEC built dedicated software factories designed around reusable modules, centralized process standards, and specialized worker roles. As Michael Cusumano documented in Japan’s Software Factories, these facilities achieved impressive coordination across massive mainframe projects. But they did not make software development as effortless as stamping sheet metal. Someone still had to figure out what the customer actually needed, how the system ought to behave, and what to do when reality refused to match the spec.
The Ghost of Frederick Winslow Taylor#
Underneath the factory metaphor lurks an older intellectual ghost: Frederick Winslow Taylor and his Principles of Scientific Management. At the turn of the twentieth century, Taylor revolutionized heavy industry with a stopwatch and a clipboard. His core premise was straightforward: workers on the shop floor should not decide how work is done. Management’s job was to study the task, determine the single best method, set precise time allowances, and enforce strict execution. Taylor’s primary text made the separation explicit: the thinkers plan, and the doers execute.
When applied to physical labor, Taylorism yielded massive gains in raw throughput. But when management brought that same mindset to software, it created a structural disaster.
In software, who owns the knowledge of how work gets done? Who sets the pace? Who gets to decide whether an unexpected edge case is a silly defect or a profound clue about a flawed architecture?
When you separate planning from execution in knowledge work, you create an adversarial dynamic. Management designs bureaucratic frameworks to control what it cannot see. The Capability Maturity Model (CMM), developed by the Software Engineering Institute, attempted to bring the statistical quality control of Shewhart, Deming, and Juran into software. The SEI report laid out five stages of process maturity. In the right hands, process visibility can shine a light on systemic bottlenecks. But in typical corporate practice, CMM quickly degenerated into a compliance trap: teams spent more energy feeding the measurement apparatus than building working software.
Then came the tragedy of Winston Royce. In 1970, Royce published a landmark paper on managing large software projects. He included a diagram of sequential stages: systems requirements, software requirements, analysis, program design, coding, testing, and operations. Today, Royce is widely blamed as the father of the rigid “Waterfall” methodology.
The irony is heartbreaking. If you actually read Royce’s original paper, he presented that sequential model as a strawman that was “risky and invites failure.” His entire thesis was that software requires continuous feedback loops, rapid prototyping, simulation, and early customer involvement. But corporate procurement departments and management consultancies ignored the text, ripped out the diagram on page two, and spent the next three decades forcing software into an artificial, linear straitjacket.
Take a step back, and you can see the two formative scars on our profession. One came from Taylor’s separation of thinking and doing. The other came from a Waterfall methodology that its own author never actually prescribed. Both promised predictability. Both instead taught us, at enormous cost, what actually matters when the work is uncertain: agency for the people closest to the problem, and room for the problem itself to change.
That lesson is why the movements that followed could say, up front, what they believed in. The industry had spent two decades learning what it could not live with, and the correction began by naming what it valued.
Why Software Is Design, Not Manufacturing#
Why does the linear factory model fail so reliably when applied to software?
The answer was articulated brilliantly by two industry legends: Frederick Brooks and Jack Reeves.
In his classic 1987 essay No Silver Bullet, Frederick Brooks pointed out that the essential difficulty of software is not typing syntax; it is the sheer conceptual complexity, conformity, changeability, and invisibility of the mental constructs we build. Brooks argued that no single management or technological breakthrough could offer an order-of-magnitude leap in productivity, because building software is fundamentally about discovering and structuring ideas, not performing mechanical labor.
Five years later, in a stunning essay titled What Is Software Design?, Jack Reeves drove the point home. In civil engineering or auto manufacturing, creating the blueprint is design, and pouring the concrete or stamping the steel is manufacturing. In software, what is the manufacturing step? It is running the compiler and linker to produce a binary! Reeves showed that the compiler does one hundred percent of the manufacturing, and it does it in seconds for pennies. Everything else we call software development (writing source code, debugging, testing, refactoring) is actually the creative, iterative act of design.
When managers treat coding as manufacturing, they assume requirements can be frozen like blueprints. But requirements are never static blueprints. In a rigorous sixteen-month case study of a major government project, researchers McGee and Greer tracked 240 delivered requirements and discovered 282 change requests, devouring over 2,400 effort-days. Their study revealed that requirements did not change because people were careless; they changed because building the software was the very process through which stakeholders discovered what they actually needed.
That does not mean all standards are bad. A survey of 64 projects by Sarma Nidumolu found that sensible standardization was associated with lower performance risk and better overall outcomes. Similarly, an empirical study of 46 software companies in Indonesia demonstrated that internal standardization helped stabilize process execution, while product success hinged on external integration and handling requirements volatility.
The lesson is subtle but vital: standardize what is understood and repeatable, but keep the discovery loop open where uncertainty lives.
The Practitioner Rebellion: Agile, DevOps, and the Andon Cord#
By the late 1990s, the pressure cooker had reached its limit. Developers were trapped in multi-year Waterfall death marches, writing phonebook-thick specification documents for systems that were obsolete before a single line of code was compiled.
In February 2001, seventeen practitioners met in Snowbird, Utah, and wrote the Agile Manifesto. Read it again, because it is easy to forget what kind of document it is. It isn’t a methodology guide or a process framework. It is a short list of values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The twelve principles that follow spell out what those values look like on an ordinary workday, and the manifesto is careful to say the things on the right still have value. They just don’t come first.
They did not declare war on engineering discipline. As Jim Highsmith noted in his account of Agile’s history, Agile was a desperate attempt to restore human balance: use plans, models, and documentation when they help you deliver, but never confuse the artifacts with the work.
I lived through that transition firsthand. In my early career, waterfall project managers made engineering agonizing. They stood as gatekeepers between engineers and the people who actually understood the business problem. We had to sneak around the bureaucracy: scheduling back-channel meetings with product managers without the project managers knowing, while engineering managers quietly taught each other to act as Scrum Masters to protect their teams. It was a grassroots, ground-up movement of people reclaiming the agency to talk to each other, with management scrambling to catch up.
A few years later, the same dynamic played out in operations. Operations and software development operated on entirely different planets: developers threw code over the wall, and sysadmins were left holding pagers at 3 AM when production melted down. At the 2009 Velocity conference, John Allspaw and Paul Hammond delivered their famous talk on ten deploys a day at Flickr, showing how shared metrics, automation, mutual trust, and blameless postmortems could bridge the gap. Patrick Debois coined the term DevOps in his pioneering work, uniting development, infrastructure, and delivery into a shared cadence.
Manufacturing contributed a parallel correction. Lean thinking arrived in software through people like Mary and Tom Poppendieck, who carried the Toyota ideas into knowledge work: deliver value to real customers, keep work flowing, respect the people inside the system, and treat uncertainty as something to explore rather than eliminate. The SEI describes modern delivery the same way, as a value stream that runs from concept to deployment, where the work is to find and remove the barriers that delay it.
Across the historical and organizational evidence, a recurring pattern emerges: organizations borrow industrial models to coordinate scale, practitioners encounter the inevitable mismatch with reality, and local corrections eventually organize into a new paradigm. That is the central thread in the management-cycle research and field studies of control within Agile teams.
Even the world’s most successful physical manufacturing system understood this human dynamic far better than Silicon Valley executives did. The Toyota Production System (TPS) became the gold standard of modern manufacturing not because it turned workers into robots, but because it treated workers as problem solvers. As Toyota explains, every single worker on the line had the authority to pull the andon cord and halt the entire assembly line the moment they saw an anomaly. Toyota knew that machines cannot improve themselves; only humans practicing continuous improvement (kaizen) can discover how to make the system better.
The Values That Don’t Expire#
Tools change. Practices change. Values are the part meant to last.
Look at what actually survived from the decades we just walked through. The tools did not, and neither did the rituals: the phase gates, the sign-off ceremonies, the vocabulary of any given era. What survived were a handful of convictions that practitioners wrote down, in plain language, once they had been burned enough times to know what was sacred.
The Agile movement put people and interactions ahead of processes and tools, and working software ahead of the paperwork that describes it. Lean thinking added respect for the people inside the system, along with flow, built-in quality, and continuous improvement. DevOps contributed trust across the wall, shared ownership of production, changes small enough to understand, and blameless learning from failure. And from Toyota, the manufacturing ancestor of all of it, came the deepest commitment: the person closest to the problem gets the authority to stop the line.
Values, principles, practices. They stack in a specific order. Values are what we care about. Principles are how those values cash out when we have to choose. Practices are the day-to-day methods we use to move. The order matters, because practices should change constantly: our tools change, our capabilities change, and a practice that refuses to move hardens into ritual. Values are the stable layer underneath, the layer we carry from one toolchain to the next.
There is also a test that separates a value from a slogan, and it is unforgiving. A value is only real when it costs something. Everyone believes in quality until the deadline. Blameless learning stays popular until an incident turns expensive. Everyone respects the people doing the work until respect starts to slow the delivery cadence. What we keep when it’s inconvenient is what we truly value.
None of this is nostalgia. Those convictions were not handed down by a vendor or decreed by a framework. They were earned, expensively, by people who tried the other way first. That is why they are durable, and why they are the most portable thing our industry owns. They don’t care what language, framework, or model happens to be writing the code.
Why the Dream Refuses to Die#
If the factory metaphor has failed so many times, why does it keep coming back?
Because coordinating humans at scale is genuinely hard. Software projects are terrifyingly expensive, fragile, and unpredictable. Leaders want predictability, investors want linear returns, and engineers want to stop wasting time on repetitive drudgery.
The mistake is never in wanting efficiency, reusable components, or reliable delivery pipelines. The mistake is confusing the mechanical execution of a known task with the human discovery of what needs to be solved. When the problem is uncertain, an assembly line does not save you; it just helps you produce the wrong thing faster.
Which brings us directly to the present. Today, AI agents are writing code, generating tests, and opening pull requests at superhuman speed. The software factory is no longer a management metaphor; it is running on servers right now, and this is the first moment where the new machinery will test whether we meant what we wrote down.
Are those values still important to us? How is the ecosystem being built right now living up to them, and where does it quietly conflict? Those are the questions I carry into Part II.
In Part II, we step into the modern AI software factory to see who holds the controls, before Part III asks what kind of future we are actually building for the humans inside it.