What’s Changed in 50 Years of Computing: Part 4
👋 Hi, this is Gergely with a subscriber-only issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. If you’ve been forwarded this email, you can subscribe here. What’s Changed in 50 Years of Computing: Part 4Is the landmark software engineering book ‘The Mythical Man-Month’ still relevant today, and what’s changed during half a century of computing in dev productivity, shipping of projects, and docs?
‘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:
Today, we near the end, covering chapters 10 and 12-15 of 16, and looking into:
1. Tooling for developer productivity, then and nowChapter 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 portableBrooks writes:
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 toolsIt used to be common for programmers to keep tools to themselves and not share them with colleagues, according to Mythical Man-Month:
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:
Since the mid-2010s, GitHub has become the de-facto place to share and list open source projects, and the portal makes discovering and contributing to open source tools easier than ever. Platform teams matter – kind ofBrooks makes an interesting observation about the need for “common tools”:
That observation feels like it could have been written today, when larger engineering teams still struggle with whether to build their own, custom solutions/services, or to integrate into internal platforms. Platform and program teams were born out of this realization at Uber, back in 2014. From the article, The platform and program split at Uber:
The need for platform teams seems to remain constant at mid and large-sized groups. Many companies at around 100 or more software engineers decide it’s sensible to create a team that takes care of the solutions used by other teams; be it infrastructure or internal services. In this way, much is unchanged since the 1970s. Indeed, the single major change I can see is that more platform teams opt to adapt open source solutions, rather than build them from scratch, thanks to open source solutions spreading rapidly. Interactive debuggers speed up developersBrooks’ book describes slow debugging as a major obstacle in the way of programming at speed:
Mythical Man-Month argues that interactive debuggers – which were rare at the time – should speed up development, and Brooks had the data to prove it:
These days, major IDEs support interactive debugging; i.e., pausing the code running at a breakpoint, inspecting and making changes to variables, and stepping into (or over) functions. These tools definitely help development, and Brooks was right to believe that better debuggers lead to faster development speed. Developer efficiency shot up from the 1970sThe book cannot help but reveal just how much developer productivity has evolved since it was published, half a century ago:
Still, developer productivity remains an elusive topic today, even though it gets plenty of attention. There are efforts to measure it more precisely at the team-level, including frameworks like DORA, SPACE, and DevEx. You may remember that consulting giant McKinsey got involved in the debate, to which Kent Beck and I published a response. We’ve also covered real world examples of measuring developer productivity, as well as how LinkedIn does it, and what Uber does. 2. Bug catching was harderChapter 13 is “The whole and the parts” and goes into detail about sensible debugging approaches for the time, and techniques for finding bugs. What hasn’t changed...Subscribe to The Pragmatic Engineer to unlock the rest.Become a paying subscriber of The Pragmatic Engineer to get access to this post and other subscriber-only content. A subscription gets you:
|
Comments
Post a Comment