What’s Changed in 50 Years of Computing: Part 4

‘The Mythical Man-Month’ by Frederick P. Brooks was published in 1975, 50 years ago. The book is still quoted today, most famously in the form of “Brooks’ Law;” the eponym that adding manpower to a late software project makes it even more late. But in many ways, computing then and now are worlds apart. So, what truths does the book still contain, or does it belong in a museum of computing history?

In a series of articles, we’ve been working through Mythical Man-Month (MMM) to see which predictions it gets right or wrong, what’s different about engineering today – and what’s the same. We’ve covered a lot of ground:

• Part 1: the joys and woes of programming, why we ship faster than 50 years ago, “Brooks’ law”, time spent coding then and now, and the concept of the “10x engineer” (covering chapters 1-3.)

• Part 2: the evolution of software architecture, communication challenges on large projects, and the ideal structure of tech orgs (chapters 4-7).

• Part 3: estimations, developer productivity with programming languages, the vanishing art of program size optimization, prototyping and shipping polished software (chapters 8-11).

Today, we near the end, covering chapters 10 and 12-15 of 16, and looking into:

1. Tooling for developer productivity, then and now. This has taken huge leaps over the decades, thanks to code becoming portable across systems and open source. It was difficult to be a productive developer decades ago.

2. Bug catching was harder. Today, there are many more tools to catch bugs and regressions with; automated tests, feature flags, and more. What has not changed is that poor specification is what tends to create unexpected bugs.

3. Shipping software projects on time. Surprisingly, almost nothing has changed in 50 years; projects slip and there’s a tendency to mask delays. Milestones and good engineering leadership matter for shipping software, predictably.

4. Importance of documentation. This used to be important, then became critical for “waterfall” development, before being deprioritized in the 2000s. Today, more detailed upfront documentation is used in the planning stages.

1. Tooling for developer productivity, then and now

Chapter 12 of MMM is “Sharp tools” and it covers ways of making developers more effective, back in the early days of computing. In the 1970s, developer productivity was a massive challenge due to rapid technological change. It’s interesting to learn how hard it was to be productive at that time because of a host of issues we don’t have to think about, today.

Dev tools weren’t portable

Brooks writes:

“The technology changes when one changes machines or working language, so tool lifetime is short.”

This was Brooks’ own experience: he worked on a new operating system called IBM 360, which was built on new hardware, which the OS development team had to build the tools to develop for. Later, devs who built programs on top of the IBM 360 needed a new set of APIs, and had to rewrite existing programs from other systems.

These days, programs are much more portable. Hardware architecture has become more standardized since the 1990s, and now change is slower. At the hardware level, architecture families like the x86 processor family, the x86-64 (the 64-bit version of the x86), and ARM allow portability of programs within an architecture family.

Meanwhile, operating systems like Windows, Mac, and Linux distributions integrate with various hardware, and upgrading to a new computer no longer means changing the operating system. Across OSs, Microsoft’s Windows is known for prioritizing backwards compatibility, so 16-bit programs can run on 32-bit Windows versions, and 32-bit programs on 64-bit Windows versions.

A level above the OS, software layers can also create cross-platform compatibility across operating systems. Examples of software platforms include the Java Virtual Machine (JVM), web browsers for running JavaScript-based web applications, and Unity for games development. We previously did deep dives on how to build a simple game, using Electron for building desktop apps, and others.

Hoarding tools

It used to be common for programmers to keep tools to themselves and not share them with colleagues, according to Mythical Man-Month:

“Even at this late date, many programming projects are still operated like machine shops, as far as tools are concerned. Every master mechanic has their own personal set, collected over a lifetime and carefully locked and guarded – the visible evidence of personal skills. Just so, the programmer keeps little editors, sorts, binary dumps, disk space utilities etc., stashed away in their file.”

This was the pre-internet age, when hoarding tools could give a developer a big edge in their work.

The internet and the rise of open source has made sharing of developer tools commonplace. Today, tools are easy enough to distribute within a team by checking them into a shared code repository, while dev tools are often released as open source for anyone to use, fork, and contribute to. There’s an ever-growing list of open source developer tools:

• Backstage (developer portal created by Spotify, which we published a deep dive about).

• Jenkins (popular build system)

• Visual Studio Code (popular IDE)

• React and Next.JS (popular frontend frameworks)

Since the mid-2010s, GitHub has become the de-facto place to share and list open source projects, and the portal makes discovering and co