[bluquark]

Brooks' definition of a silver bullet was "an order of magnitude improvement" and certainly none of those innovations individually come anywhere close. But I agree it's plausible that combined they might amount to one single order-of-magnitude improvement (as compared to average early-1980s development), for the subset of organizations that apply all of them together effectively.

In my personal experience at my workplace I've certainly observed many times that the quote "Adding manpower to a late software project makes it later." is not universally true. When things go well, onboarding an experienced engineer and assigning them a parallelizable task has often proved a relatively lightweight process on teams I've been on, and I've seen the new member's productivity rapidly exceed their communication burden on the rest of the team.

That might be explainable by how several of the innovations you listed reduce the need for communication between humans. For example, we now need less communication about regressions since CI/CD alerts the responsible party immediately, and we need to ask fewer questions when individuals can examine the entire history of a codebase in version control themselves.

(That doesn't mean Fred Brooks's work is now obsolete, this story is consistent with Brooks's underlying analysis of the problem.)

[kaba0]

An often under-appreciated part of the original paper is effectively libraries - code you don’t have to write yourself.

This is absolutely the biggest contribution to productivity improvements over that time period, and I think that we don’t always make good use of them (NIH syndrome, it’s not written in my favorite language, etc). Seriously, if there is a good quality library for the task already, just use it! That’s why python is where it is today in the data science community, and is also the reason why I will start any new project on the JVM unless there is a good reason not to. (The third contender for the biggest ecosystem is JS, and while it has similarly vast amount of packages, I found their average quality is behind that of the JVM’s)

[sokoloff]

What fraction of late projects have all those ingredients in place and readily identified, parallelized tasks needing to be started? I feel like part of the Brooks quote’s premise is that late projects got that way by some reason and those reasons are rarely amenable to more bodies. (That’s to suggest “if you have a choice to add programmers to a late project or an on-schedule one, you might be better off doing the latter if overall delivery is your goal.”)