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
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?
The “10x engineer,” then and now
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. 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: