The things you mentioned are not silver bullets, as Brooks defined them. A "silver bullet" is a:

>single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.

To take an easy example:

>We've got GIT, which is a huge improvement over ZIP files of source code stored on floppy disks.

This is a huge improvement over the previous flow of passing around ZIP files, but it doesn't yield an order of magnitude gain in overall productivity for a dev team. For it to yield a 10x improvement, it would mean that programmers were spending at least 90% of their time passing around source code.

It's for sure an order of magnitude improvement on the subtask of code collaboration, but it's not a silver bullet in itself.

I think collectively there have been advancements that have produced an order of magnitude improvement in dev productivity, but Brooks' claim was that there would be no one thing that eliminated 90% of a developer's work.

"overall productivity" isn't necessarily the bar. If you're spending 1 hour a week managing git and you used to spend 10 hours a week managing zip files, it's an order of magnitude improvement.

I'm not sure what you mean.

If we're evaluating whether Brooks was correct in his "no silver bullet" prediction, then overall productivity is the bar because his prediction was about overall productivity of a dev team.

I agree that git improves productivity over passing around zip files, but it doesn't disprove Brooks' prediction.

Fair point, in the context of a silver bullet his intent was clearly to describe a single thing that improved productivity across the board. I had to go re-read the paper to reset my perspective.

I get your point but, no, it’s not for the same reason Amdahl’s law exists: if you already weren’t taking any significant time on something, even cutting the whole thing out would give you negligible benefits.

Who cares. When the first silver bullet tech that appeases his requirement comes along, my blog post will require 100x improvements in productivity, reliability, and simplicity.

GIT was based on previous version control system, PVC, SVN, etc. And it is probably more complicated to use than the older version were.

Git is possibly better at distributed teams.

> We've had a lot of tools that were orders of magnitude faster than previous approaches to programming. Visual Basic/VBA/Delphi/Hypercard et al, made it possible for domain experts to get usable applications built, with little to no programmer involvement. That was a HUGE improvement in our productivity.

Until it needs to maintained and scaled.

My first job out of college was to rewrite a data entry system for a state government used to enter crime statistics. They used Microsoft Access.

Well, if the domain expert wrote the first pass at it, think of the cycles of writing specifications, design, programming, and only then finding out the specs were wrong, got skipped.

That's a huge time savings, and as a bonus you have working code to refactor or use as a specification.

Microsoft Access is an amazing database, it manages related tables automatically, and can scale up to working with ODBC and SQL database back ends easily.

This the the normal progress Brooks wrote about. Yes, we have things that have made our lives better or allowed us to make the things about programming that are accidentally hard, easier.

The no silver bullets means that there is no magic that is going to make all parts of software development easy or instant. Some parts of creating software is still hard and might very well always be hard. Getting good requirements is one of those things that has been hard, still is hard, and might be hard for as long as we are building software.

> Visual Basic/VBA/Delphi/Hypercard

Most of these are gone. Not replaced by something better IMO. Excel is holding on though.

> We've got IDEs that compile in a flash, compared to the interminable compiles of the past. That's a huge improvement to productivity.

Compilers are faster, IDEs got slower. Tech stacks got fat. Things got distributed. Shit’s complex now.

But I’ll give you git. Git is a win indeed.

We also have cloud servers now, meaning deploying your application is a credit card swipe away, instead of having to set up and maintain your own servers.

> We've got GIT, which is a huge improvement over ZIP files of source code stored on floppy disks.

Real Programmers stored their source code on magnetic tapes, that is if they weren't using punch cards or paper tapes. RCS, the first open source version control system, predates PKZIP by a good five years, and SCCS, the first version control system, is only a year younger than the first commercially available floppy disk drive.

But never mind that. Git was at most an incremental improvement over its direct predecessor, BitKeeper, or the other popular version control systems at the time, like Subversion. Git wasn't even unique. The open source DVCSes Arch, darcs, and Monotone all predate Git, and Mercurial was started just a few days after Git. Our hacker parents and grandparents might be old, but they aren't _savages_. ;)