From Apollo 11 to Agile: How Software Engineering Killed the Art of Programming

We live in an era where software governs everything from our microwave ovens to the steering columns in our cars. Yet, the modern software industry has largely lost its connection to the deep, disciplined artistry that defined its early years. To understand how we arrived at a landscape dominated by rigid project management and "flaccid Scrum," we have to look back at the radical evolution of programming from the 1940s to today.

The Human Computers of WWII and the ENIAC 6

In the early days of computing, writing code was heavily viewed as "women's work." During World War II, the military required immense calculations for ballistic trajectories and cryptography, and women filled these roles. At Bletchley Park, female cryptanalysts like Joan Clarke worked closely with Alan Turing to break the Enigma code.

In the United States, the military built the first all-electronic, programmable computer, the ENIAC. The hardware was designed by men, but the machine was programmed entirely by six female mathematicians: Jean Bartik, Kathleen Antonelli, Marlyn Meltzer, Frances Spence, Ruth Teitelbaum, and Betty Holberton. They were handed blueprints of a massive, top-secret machine with 3,000 dials and told to teach themselves how to program it. Around this same era, pioneer Grace Hopper, who served in the US Naval Reserve, invented the first computer compiler and laid the structural foundation for COBOL, fundamentally shifting programming from raw machine code to readable languages. It was an era defined by mature professionals practicing software as a precise, mathematical art.

The 1960s Golden Age and the Moon Landing

As hardware evolved into the 1960s, it remained incredibly limited. The computers of that era had a tiny fraction of the memory and processing power of a modern smartphone. Yet, the programmers of the 1960s accomplished miracles.

During the Apollo 11 mission, the guidance computer had roughly 4 kilobytes of RAM. As Neil Armstrong piloted the Lunar Module toward the moon's surface, the computer was suddenly overwhelmed with unexpected radar data, triggering the infamous 1202 program alarm. Had the system frozen, they would have had to abort. However, the programmers—led by software engineering pioneer Margaret Hamilton, who literally coined the term "software engineering" to elevate the discipline's status—had built the code as an asynchronous executive. The software was artistic and brilliantly resilient; it recognized the overload, dropped low-priority background tasks, and kept the critical thruster controls alive.

The Demographic Shift: Why the Numbers Plummeted

Through the 1970s, women continued to be a major force in computing. In fact, by 1984, women made up 37% of all computer science undergraduate majors in the United States. However, around that same time, a massive demographic shift occurred, and the numbers plummeted.

The advent of early personal computers, such as the Commodore 64 and the Tandy TRS-80, changed the cultural landscape. These machines were marketed almost exclusively to boys as gaming toys. A cultural narrative took hold—fueled by movies, media, and advertising—that computers were for "nerds" and young men. By the time students reached college, young men had years of informal hardware and basic programming experience at home, leaving women structurally disadvantaged in the classroom. As the software industry's workforce ballooned, doubling every five years, the mature, gender-balanced workforce of the past was entirely overrun by a massive influx of inexperienced, twenty-something men. By the 2010s, the percentage of women in computer science had dropped below 20%.

The Mistake of Waterfall

This sudden surge of youthful coders created a crisis for businesses: how do you manage hordes of young men who lack the intrinsic discipline of the previous generation?

Management found their answer in 1970 when Winston Royce published a paper detailing the Waterfall model. Royce actually intended the diagram to be a strawman—an example of a flawed, risky way to build software. But management ignored the warnings. They took the picture, pasted it into their corporate manuals, and Waterfall became the industry standard. The artistry of programming was suddenly buried under layers of top-down bureaucracy, rigid documentation, and project managers trying to tightly control the code.

Kent Beck and the Birth of Extreme Programming

By the mid-1990s, the software world was suffocating under the weight of Waterfall's heavy documentation and delayed feedback loops. Projects were massive, rigid, and routinely failed to deliver on time.

The tipping point occurred in 1996 when software engineer Kent Beck was hired to salvage the Chrysler Comprehensive Compensation (C3) system, a sprawling, troubled payroll project. Beck realized that traditional management techniques wouldn't save the project. Instead, he decided to strip software development down to its most effective technical habits and turn the dial up to ten.

He formalized these habits into core engineering practices. He reasoned that if testing is beneficial, it should be done before any production code is even written—resulting in Test-Driven Development (TDD). If code reviews improve quality, developers should review code continuously—leading to true Pair Programming. He called it Extreme Programming (XP). XP was an audacious pushback against corporate bloat. It treated software development not as a predictable manufacturing assembly line, but as a disciplined, deeply collaborative, and intensely technical craft.

The Mid-90s Rebellion and the Agile Manifesto

The C/C++ hackers of the 90s—practitioners of what many consider the last great "artsy" era of low-level programming—were also pushing back against the heavy, slow-moving Waterfall lifecycle. Programmers wanted to return to a craft where they were trusted to build resilient architectures without months of upfront paperwork.

This broader rebellion culminated in 2001 when a group of 17 software veterans, including Kent Beck and Robert "Uncle Bob" Martin, retreated to Snowbird, Utah. They drafted the Agile Manifesto, an attempt to heal the growing divide between business and programming. Their weapon of choice was the underlying philosophy of Extreme Programming, which demanded intense technical discipline to allow for rapid, flexible responses to changing business needs.

How Engineering Killed the Art

Unfortunately, the Agile revolution was hijacked. Business managers understand discipline and meetings, but they do not fundamentally understand technical engineering practices. You cannot ask a manager for permission to write tests or refactor code; that risk belongs solely to the programmer.

Because of this disconnect, the industry largely abandoned the rigorous technical practices of Extreme Programming in favor of Scrum. Legions of project managers got certified in Agile without ever writing a line of code, turning the movement into a heavily managed, business-driven process completely devoid of technical excellence. This resulted in "flaccid Scrum"—highly efficient meeting schedules attached to chaotic, undisciplined engineering codebases.

This shift is mirrored in the evolution of our programming languages. The raw, artistic power of 90s-era C/C++ is dying out, replaced by higher-level languages designed to be as close to business logic as possible. We can see this trajectory in the history of enterprise development, elegantly detailed in Uncle Bob's talk on the early challenges and future of Java. On the other end of the spectrum, we see older languages being completely resurrected by modern business needs, as shown in the rebirth of Python as the undisputed king of the AI and data science boom.

As software continues to eat the world, we can no longer afford to treat coding as a sterile, bureaucratic assembly line. We must reclaim the discipline of the Apollo engineers, the artistic craftsmanship of the 90s hackers, and the unyielding technical rigor of Extreme Programming.

Citations & Research Context

Below is a detailed breakdown of the sources used to construct this history, including why each was included to fulfill the narrative requirements of the article.

• Uncle Bob Martin - "The Future of Programming" (Video Link Opens in a new window ):

  • Why it was added: This lecture provides the core structural argument of the piece. It outlines how the demographic shift of the 1970s and 80s brought in undisciplined youth, leading management to impose Waterfall, and eventually culminating in the drafting of the Agile Manifesto at Snowbird to reclaim technical discipline. It highlights the drastic shift from an older, gender-balanced workforce to a male-dominated one.

• National WWII Museum - Admiral Grace Murray Hopper: When Women Were Computers (Source Link):

  • Why it was added: To verify the history of women as the earliest "human computers." This source confirms Grace Hopper's foundational contributions, including the invention of the first compiler and her efforts leading to COBOL, contrasting the later male-dominated software engineering industry with its female-driven roots.

• NPR Planet Money / EdTech Magazine - Did the Computer Science Gender Gap Begin in 1984? (Source Link):

  • Why it was added: You requested an explanation for the decline of women in the field. Research shows that female participation in computer science actually peaked around 1984 at 37% before plummeting. This source correlates the drop directly to the rise of early personal computers being heavily marketed as toys for boys, fundamentally shifting the cultural perception of who a "programmer" was.

• Medium / Tech History - The ENIAC Women (Source Link):

  • Why it was added: To highlight the specific pioneers of early programming. This source details how the original six programmers of the ENIAC machine were all women who had to teach themselves to program massive hardware using nothing but raw circuit diagrams.

• GitHub / Julien Simon - Apollo 11 AI Walkthrough (Source Link):

  • Why it was added: To provide deep research on how 1960s programmers sent a man to the moon with minimal hardware. This verifies Margaret Hamilton's leadership at NASA and confirms that her "asynchronous executive" software design saved the mission by gracefully dropping low-priority tasks during the 1202 program alarm.

• Hacker News / Medium Articles on Winston Royce (Source Link):

  • Why it was added: You requested details on how the Waterfall model originated. Research confirms that Winston Royce's 1970 paper presented the top-down step-by-step model as a flawed example (a strawman) that needed iteration. Management ignored his warnings and adopted the diagram verbatim.

Why Middle Management Hates Extreme Programming (And Why I Loved It)

 We rarely see true Extreme Programming (XP) in the wild anymore. When it does happen, it is usually a fleeting, beautiful experiment before the traditional metrics and middle management pushback take over. I had the privilege of experiencing pure XP firsthand, and it completely reshaped my understanding of what software development could be.

The Ultimate Two-Keyboard Setup

The experience started when we brought in a developer from the Bay Area. We decided to commit fully to the bit. We procured a top-of-the-line iMac loaded with 32 GB of RAM and the largest screen available. But the real magic was the input configuration: two people sitting side-by-side, sharing one massive monitor, with two keyboards plugged into a single machine.

This was pair programming in its most unfiltered form. There was no "Code With Me" screen sharing, no network latency, and no hiding behind a muted microphone. It was an intense, synchronous mind-meld that remains the absolute best programming experience of my career.

The TDD Time Machine

Alongside the pair programming, we strictly adhered to Test-Driven Development (TDD). Writing the tests first and watching the architecture naturally emerge from the constraints was an intellectual thrill.

Practicing TDD in that environment felt exactly like being transported back to university, sitting in a rigorous Algorithms class. It forced a level of deep, analytical thinking that daily enterprise development often smooths over. We were solving puzzles in real-time, holding each other accountable for every line of code, and building software that was virtually bulletproof from the moment it compiled. It was pure, unadulterated fun.

The "Waiting for Godot" Reality

Unfortunately, experiences like this rarely last. The reality of the corporate software world is that middle management fundamentally does not like Extreme Programming. It looks expensive on a spreadsheet to have two highly paid engineers working on a single machine, even if the resulting code requires a fraction of the QA and maintenance time.

Eventually, the initiative began to feel a bit like Waiting for Godot—an endless anticipation for a paradigm shift across the organization that was never actually going to arrive. Because true TDD and XP require constant practice and a supportive environment, I have unfortunately forgotten much of what I learned during that brief, golden era. Without the right setup and institutional backing, those sharp skills inevitably dull.

The Broader Evolution of Craft and Language

Reflecting on that XP experience naturally leads to thinking about how our tools and languages have evolved around us. The discipline of writing good code remains constant, but the ecosystem is always shifting.

For Java developers navigating the modern enterprise landscape, understanding where we came from is crucial to understanding where the language is heading. Uncle Bob provides a fantastic breakdown of this in his talk on the early challenges and the future of Java, detailing the architectural decisions that shaped the language.

On the other end of the spectrum is the incredible resurgence of Python. It is fascinating to watch one of the older languages get completely re-birthed by the data science and AI boom, transforming into the dominant language of the current era. This trajectory is captured perfectly in this documentary on the history and rebirth of Python.

Whether you are pair programming on a massive iMac or writing solo microservices, the core lesson remains: the tools and management trends will constantly change, but the pure joy of solving a complex algorithmic problem with a great peer never fades.