What Changed in 50 Years of Computing: Part 1
How has the classic book on software engineering, ‘The Mythical Man Month,’ aged with time, and is it still relevant half a century on – or does it belong in a museum, alongside floppy discs?
‘The Mythical Man Month’ by Frederick P. Brooks, Jr. is a bona fide classic in the software industry. First published in 1975, and with an updated edition in 1995, the text is almost 50 years old. Lots of time has passed, yet the book is still relevant.
The title of the book takes aim at the “myth” that software development can be measured in “man months,” which Brooks disproves in the pages that follow:
“Cost [of the software project] does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth.”
I’ve been making my way through this book from software’s earliest days and taking notes of what’s remained the same in the 50 years since Mythical Man Month came out, which predictions the book got right or wrong, and what’s different about engineering today.
The author worked at IBM as a project manager of the OS/360 operating system, one of the most complex software projects in the world, at the time. Possibly the book’s most famous insight is that adding manpower to a software project that’s already behind schedule will delay it even more – which likely comes from Brooks’ personal experience at a big company. This insight seems obvious to many of us today, but it was Brooks who saw it first, which speaks to why the book still matters.
In today’s issue, we cover reflections on Chapters 1-3 of the book:
A criticism of the book: gendered language
Joys and woes of programming, then and now
The “10x engineer,” then and now
Why do we ship faster now than in 1975?
Does “Brooks’s law” still apply?
Do we spend more time coding than 50 years ago?
We follow this review in later parts:
Evolution of architecture approaches
Architecture approaches: what’s the same
Communication challenges on large projects: then and now
Ideal structure of tech orgs
Estimations
Developer productivity
The vanishing art of program size optimization
Prototyping
Back to the ‘70s? Shipping polished software, not MVPs
1. A criticism of the book: gendered language
One thing modern readers will notice is that only the male pronoun is used throughout. Brooks was writing in the early-mid 1970s, when there were plenty of women programmers in the field. Indeed, it’s estimated that in the 1960s between 30-50% of all programmers were women, by the book Broad Band: The Untold Story of the Women Who Made the Internet by Claire L. Evans.
Despite the reality, the Mythical Man Month exists in a workplace populated entirely by other men. Every engineer is a “he,” and “he” does the programming, testing, and documenting. The invisibility of women in the text seems a puzzling omission today; second-wave feminists might say it illustrates why their struggle against engrained discrimination and inequality had to happen.
Women in software at the time included Jean E. Samme, who published the book Programming Languages: History and Fundamentals in 1969 – one of the most popular books in the field. Meanwhile, Margaret Hamilton was responsible for programming the onboard flight software for the Apollo space mission. Not only that, she’s also credited with coining the term, “software engineering.”
The absence of women was partially rectified in the later edition, in which four new chapters were added. The 1995 volume uses “people” instead of the male form, and drops “he” as the default gender.
Now, let’s reflect on the rest of the work.
2. Joys and woes of programming, then and now
In Chapter 1, “The Tar Pit,” Brooks asks why programming is fun, and gives five reasons:
Joy. “The sheer joy of making things.”
Usefulness. “The pleasure of making things that are useful to other people.”
Complexity. The fascination of unique complexity. “The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.”
Learning. The joy of always learning, which happens in programming because tasks are non-repeating.
Using your imagination. “Building castles in the air” by creating things by exerting your imagination. Software is very easy to polish and re-work, which is rare in most industries.
I like to think these all are still true, and would add more reasons why coding is increasingly popular in 2024:
The world runs on software. It’s hard to find any industry in which software is not embedded, these days. If you run a business, you’ll need to work with, and likely want to customize, software. This means that if you know how to code, it can be easier to understand the industry you’re in, and run a business.
It’s a lucrative career. Software engineers have high earning potential, and often more flexible working environments than most professions. A good chunk of jobs are full remote, and those which aren’t rarely require being in the office more than 3 times per week. Experienced software engineers are in demand-enough and many companies relocate and sponsor visas to hire the talent they need, which is generally rare.
The biggest startup success stories have been tech companies. In 1975, when “The Mythical Man Month” was published, the most valuable companies in the world included General Electric (electronics,) Exxon (oil,) AT&T (telecommunications,) and Procter & Gamble (consumer goods.)
Fifty years later, here’s the largest companies by market cap, with details of their founders:
Microsoft (founded 1975 by programmers Bill Gates and Paul Allen)
Apple (founded 1976 by visionary leader Steve Jobs, and hardware engineer Steve Wozniak, and programmer Ronald Wayne)
NVIDIA (founded in 1993 by microchip designers, Jensen Huang, Chris Malachowsky, and Curtis Priem)
Saudi Aramco (non-tech, founded 1993; the Saudi state oil company)
Amazon (founded 1994 by Jeff Bezos – who’s an entrepreneur with a degree in computer science and electrical engineering; thus knows how to code)
Google (founded 1998 by programmers Larry Page and Sergey Brin)
Meta (founded 2004 by programmer Mark Zuckerberg)
Today, six of the world’s largest publicly traded companies are tech businesses, all were created by technical people (Jeff Bezos isn’t a programmer, but has computer science background,) and most founders were developers at the time!
By comparison, let’s look at where the top companies in 1975 are, today:
20. Exxon Mobil ($413B market cap)
25. Procter & Gamble ($375B market cap)
72. General Electric ($175B market cap)
118. AT&T ($16B market cap)
The fact that many of the most valuable companies today were founded by programmers or hands-on tech people, is a massive motivation to learn programming. Considering the biggest corporate success stories of the recent past, it’s unlikely the next one will have a founder who knows nothing about technology and coding.
Woes of programming
And what are the biggest challenges of building large systems? Brooks identifies some:
Precision. “If one character, one pause (...) is not strictly in proper form, the magic doesn’t work.”
Lack of full control. “One rarely controls the circumstances of his work, or even its goal. In management terms, one’s authority is not sufficient for his responsibility.”
Dependencies. “[The programmer] depends upon other people’s programs. These are often maldesigned, poorly implemented, incompletely delivered (no source code or test cases), and poorly documented.”
Once the fun wears off, it’s just work. “With any creative activity comes dreary hours of tedious, painstaking labor; and programming is no exception.”
Debugging is hard. “One finds that debugging has a linear convergence, or worse, where one somehow expects a quadratic sort of approach to the end.”
By the time the product is ready it’s almost obsolete. “Already colleagues and competitors are in hot pursuit of new and better ideas.”
I agree with these observations, which are still relevant today, except for perhaps two:
#1: precision. It’s true programs need to be precise, but we have so much better tooling for spotting compile-time errors than in 1975 and 1995. Functionality editors like Visual Studio, JetBrains studio, and other IDEs (integrated development environments) make spotting errors early much easier.
#6: Obsolescence at launch. In the last two decades, startups have pivoted to a leaner model of shipping MVPs (minimum viable products) rapidly in weeks or months, not years. This means the product is not obsolete on launch. But the tech industry keeps changing, and it is hard to keep up!
A few modern challenges for anyone writing code:
Too much choice. We are spoilt for choice for technologies to use. For writing a backend service, you can pick from close to a dozen languages, and a handful of frameworks. On the web, there are plenty of frameworks to choose from. On mobile, you need to decide to build natively, or use a cross-platform framework. These choices are good problems to have, but can also be overwhelming!
Higher-level abstractions are sometimes harder to debug. High-level frameworks have their own problems, and can be tricky to debug. React is one example of a framework which is very powerful, but is the opposite of intuitive to pick up, or to debug odd edge cases with. It’s not alone; every opinionated framework struggles to pinpoint why certain edge cases occur.
In his first chapter, Brooks concludes: “for many [programmers] the joys far outweigh the woes.” This hasn’t changed, and building software remains rewarding for most people in the industry.
3. The “10x engineer,” then and now
Chapter 3 is “The Surgical Team,” and contains what might be one of the very first mentions of the “10x engineer” concept. This is how Brooks put it:
“Programming managers have long recognized wide productivity variations between good programmers and poor ones. (...) In one of their studies, Sacknman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances average about 10:1 productivity measurements, and an amazing 5:1 on program and speed space measurements! In short, the $20,000/year programmer [in 2024 terms: $120K] may well be 10 times as productive as the $10,000/year one [in 2024 numbers: $60K].”
Brooks agrees with this observation, and suggests a radical solution: have as few senior programmers as possible, and build a team around each one – a bit like how a hospital surgeon leads a whole team. Brooks suggests the set up below, borrowed from Harlan Mills, could work well:
The chief programmer. Brooks calls this person “the surgeon.” They write the specification, code, tests it, and write the documentation. Has 10+ years’ experience, and a broad range of expertise across developing, math, business, and whatever else is needed.
The copilot. “The alter ego of the surgeon, able to do any part of the job, but less experienced.” This is a bit like a junior pair-programming partner.
The language lawyer. “Most computer installations have one or two people who delight in mastery of the intricacies of a programming language. These experts turn out to be very useful, and very widely consulted.” This role implies the chief programmer will usually not have time to go in-depth on a programming language, and will rely on an expert in it. A most interesting addition!
The toolsmith. Responsible for building and maintaining developer tools so the programmer and copilot can do their jobs better; such as improving editors, building better debugging functionality, creating utility tools and macros, etc.
The tester. They come up with test cases and data. Also responsible for scaffolding of tests.
The program clerk. “Responsible for maintaining the technical records of the team in a programming-product library, responsible for both machine-readable and human readable files.”
The administrator. Responsible for payroll, renting offices, buying computers, etc.
The editor. Edits documentation the chief programmer writes, and makes it production-ready.
Two secretaries. “The administrator and the editor will each need a secretary; the administrator’s secretary will handle project correspondence and non-product files.”
Here’s what this “surgical team” built around a very productive programmer looks like:
My sense is this team setup was aspirational. The roles certainly made sense at the time, but why would any business leader sign off to hire 9 other people to support one developer? In 1975, I assume the answer was very few.
In 2024, there is no need for most of Brooks’ proposed roles, and the “surgical team” has transformed thanks to advancements in tooling and how we work:
It’s fascinating how much tooling has improved in 50 years. Tools and approaches at our disposal, which didn’t exist in 1975, or were not widespread in 1995, include:
Git – the now-dominant version control system used by much of the industry, with exceptions for projects with very large assets, like video games
Code reviews: these became common in parallel with version control. Code reviews reduce the need to pair while working on a task, allowing engineers to keep up with changes and learn from each other.
CI/CD: running automated tests on all changes, and deploying code to production automatically.
Rollout and rollback mechanisms. Brooks discusses software in the context of producing operating systems, pre-internet. Building operating systems and embedded software remains challenging, but software updates over the internet are common and bug fixes can be delivered later. A good example is automobiles; most modern vehicles regularly refresh firmware and operating systems “over the air!”
Picking up languages and frameworks is easier. There are countless online resources, sandboxes, and advanced IDE functionality like autocomplete and inline signaling for compile-time errors, that make getting started with a new language much easier, today. To come right up to date, we’re currently discovering the productivity impact of AI coding tools.
Progress has changed what used to be a 10-person team supporting a lead developer, into a set of tools, as well as a couple of centralized platform teams, at larger companies.
The concept of “hierarchical programming” feels dated. One thing that strikes me about Brooks’s model is that it’s hierarchical. The “chief programmer” acts as an architect and does all planning, most direction setting, and some coding, while everyone else works well-defined, supporting roles. The copilot is described as:
“knows all the code intimately. [They] research alternative design strategies. [They] obviously serve as an insurance against disaster to the surgeon. [They] may even write code, but are not responsible for any part of the code.”
This setup made sense when access to computers was more limited because machine time was expensive, but, today, it would be wasteful to not have even an entry-level engineer writing production code. What didn’t exist back then was source code control and code reviews to stop poorly written code making it to production.
It’s a good reminder that tooling changes a team’s social dynamics. Thanks to better tooling, we are able to reject overly hierarchical team structures these days.
Brooks’ “toolsmith” concept is still valid, but different. I am intrigued by the role for a dedicated developer to build better debugging tools and utilities, and also by an addition to it:
“Each team will need their own toolsmith, regardless of the excellence and reliability of any centrally provided service. Their job is to see to the tools needed or wanted by the surgeon, without regard to any other team’s needs.”
Brooks was convinced that even with a central tooling team – which we’d call a platform team, today – there was still plenty of value in a team-specific tools specialist. But this need has vanished almost entirely because tools, developer environments, build tools, and more, can be configured in detailed ways.
All teams at a company use the same CI/CD tools, but they might change the configurations slightly.
It’s true that within an engineering team, there’s usually one or two engineers who enjoy tweaking build systems and shared environments more than others do. However, with central platform/infrastructure teams, there’s no need for an “embedded” platform engineer in teams. This has to do with how much developer tools have evolved in the 50 years since the book came out.
The “10x engineer” has always been a source of debate and contention. We’ve all seen developers who seem to be a lot more productive than others. CTOs and CEOs catch on to this as well, and some label standout folks as “10x developers.”
However, there’s a lot of nuance:
A developer who builds things rapidly might do so by writing unmaintainable code that several developers will struggle to modify, later
The “10x developer” might be someone who hoards information, and is effective because they refuse to let others understand obscure systems they build
A “10x developer” could be far more productive because of their long tenure at a workplace with high turnover
Another “10x developer” could be someone with good business sense, working on the most profitable projects, who avoids other work
Another “10x developer” could also be very good at taking credit for work done by a larger team, which they finished
You see where this leads. “10x developer” behavior can actually be undetected toxic behavior under a different label. Meanwhile, others could have the advantage of a specific context that cannot be replicated. It’s certainly a complex topic, and one we haven’t stopped thinking and arguing about for more than 50 years, across the industry.
4. Why do we ship faster now than in 1975?
Chapter 2 of the book is , “The Mythical Man Month,” and is one of the most quoted parts of the book. It analyzes why most software projects take longer than planned. Brooks gives five reasons: