The pace of technological change is ever accelerating and with the advent of LLMs like ChatGPT even technologists are feeling like they can't keep up. (Tom Scott link)
Despite this a 50 year old computer science book using a case study from the 1960s remains one of the most quoted and prescient books about how modern software is written and contains clues about how to best prepare ourselves for this unknown future.
The Mythical Man-Month - Fred Brooks’ Legendary 1975 book about the development of the IBM System 360 mainframe was the first to identify that adding more developers to a failing software project will often make it slip further behind schedule.
This counter intuitive rule entered the software development lexicon as Brooks' Law and it's truth is a corner stone of how agile development works, how tiny startups unseat monolithic incumbents, and why Amazon organise developers around "pizza teams" (a team that can be fed by two pizzas).
Despite being puzzling on the surface Brooks’ law can be explained with a simple diagram.
Communication is the cornerstone of a product team and the number of communication links between people scales much faster than the number of members on the team. For the mathematically inclined, communication links scale with the formula:
n(n − 1)/2
…so a while a team of 2 has a single communication link, a team of 3 has 3, and a team of 4 has 6. A flat team of 50 has to maintain 1,225 lines of communication. Eventually the overhead of keeping everyone synchronised becomes more work than the capacity a new member brings to the team; and adding a member reduces productivity instead of increasing it.
This is why Google and Microsoft haven’t been able to turn making software into a production line like Henry Ford. You can only have so many people on your team, so it pays to have the best you can afford. As a result, salaries for product teams in MAMAA (Microsoft, Apple, Meta, Amazon, Alphabet) end up like salaries for footballers. (Brooks also predicted this in the same book). In football you can't just put 50 mediocre players on the pitch and swarm the opposition, you have to play your best 11 and the same is true in product development.
To condense this to a sentence: “The output and quality of your best 10 developers is the rate limiting factor of your product”. This truism accounts for the never ending hunt for the 10X developer and why tools and techniques for developer productivity are so important.
While Brooks’ Law is known by most project managers and developers, a much lesser known concept from the same book is that of the “Code Surgeon”. Brooks reasoned that because high performing developers are such a prized commodity and you can only support a relatively small number of them on a given product team they should be treated much the same as a hospital treats its surgeons.
In an operating theatre you will never see a surgeon selecting the scalpels, applying suction, or monitoring the anaesthesia. They focus only on the part of the job where they provide the most value.
This specialisation already exists to a degree, but assigning a personal QA, automation engineer, technical writer, business analyst, and junior developer to each senior engineer would be prohibitively expensive and adding them to the team as collective resources adds to the communication links in the same way adding an additional developer does.
This is where the power of ChatGPT and Copilot really shines. Members of my team have explained their experience of using ChatGPT as like having an endlessly eager junior developer assigned to pair program with them. On a recent project with a challenging timescale a dev commented to me that usually on such a project the documentation, or test coverage, might suffer, but they were able to delegate much of this work to ChatGPT and focus only on the complex and most value adding work of optimising the algorithm.
By smart use of generative AI we can all become code surgeons.
I wonder what Fred Brooks would make of it?
.jpg)