Thread by @wycats

I periodically remind myself that Fred Brooks had everything figured out in "No Silver Bullet"

The context of that article was a debate about whether the right way to improve productivity is to search for "new paradigms" for software, or whether we get improvements through workflow and human factors.

For me, the standout quote of the entire thing is, when talking about the benefits of getting working systems as quickly as possible.

"The morale effects are startling"

They sure are.

The article also covers some reasons that reducing "complexity" purely through improved programming paradigms doesn't really address a lot of the complexity in software.

1. Sometimes software is forced to do annoying things because it's copying someone else

"In many cases, the software must conform because it is the most recent arrival on the scene. In others, it must conform because it is perceived as the most conformable.

"But in all cases, much complexity comes from conformation to other interfaces; this complexity cannot be simplified out by any redesign of the software alone."

2. Sometimes the context in which the software was written changes.

It could be new use-cases that come from adoption.

"First, as a software product is found to be useful, people try it in new cases at the edge of or beyond the original domain.

"The pressures for extended function come chiefly from users who like the basic function and invent new uses for it."

It could be new requirements that come from new hardware.

"Second, successful software survives beyond the normal life of the machine vehicle for which it is first written.

"If not new computers, then at least new disks, new displays, new printers come along; and the software must be conformed to its new vehicles of opportunity."

Or it could just be regulation or other cultural changes.

"In short, the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product."

But these things happen, and account for a huge amount of the change forced on software. Attempting to insulate your software from these changes ahead of time eats away at the productivity gains we're looking for, so that solution doesn't really address the challenge.

When people talk about "accidental complexity" as defined by this essay, they're often conflating two kinds: self-inflicted accidental complexity caused by the structure of programs, and environmental complexity outside of the control of the programmer.

Fred Brooks' argument in this essay is that the latter is much more important, and accounts for much more of the remaining productivity challenges than the former.

However elegant your programming language, adapting for GDPR takes time, and it's not in your control.

While Brooks says that paradigm shifts are unlikely to result in massive productivity improvements, he is hopeful about other approaches.

It is this section of his essay that he is the most prescient.

1. "Buy versus build. The most radical possible solution for constructing software is not to construct it at all."

"The key issue, of course, is applicability. Can I use an available off-the-shelf package to perform my task? A surprising thing has happened here.

"During the 1950's and 1960's, study after study showed that users would not use off-the-shelf packages for payroll, inventory control, accounts receivable, and so on.

"The requirements were too specialized, the case-to-case variation too high. During the 1980's, we find such packages in high demand and widespread use. What has changed?"

When Brooks was writing, the "snowflake" perspective that we sometimes find today in software development was still very fresh in other domains. Brooks is asking: why does it turn out that the mass market can share business software?

He argues, in 1987, that the explanation is not that businesses have consolidated and become more homogeneous, nor that the packages have become substantially more general-purpose.

"Not the packages, really. They may be somewhat more generalized and somewhat more customizable than formerly, but not much. Not the applications, either. If anything, the business and scientific needs of today are more diverse and complicated than those of 20 years ago."

Instead, he suggests that the explanation is that people in the 1960s were spending hundreds of thousands of dollars on hardware, and felt they could afford to throw in for custom software.

By the 80s, hardware was cheap enough that there was a growing market for people who *needed* things like payroll software but couldn't afford to build it themselves.

And to circle back to the beginning, the morale and productivity effects of working systems are extraordinary. This much is obvious.

To this day, the programming ecosystem spends too much time chasing paradigms, and not enough time on developer morale and workflows.