— tldr — 23 min read
I recently read The Mythical Man-Month by Frederick Brooks. This book continually shows up on various recommended reading lists for folks working in technology, so I thought I would give it a go. I read the anniversary edition, which was published in 1995, 20 years after the first edition. The first 15 chapters are directly from the first edition, with later chapters either being new content or commentary on previous content.
Normally I would transcribe the notes I take during reading into a summary article. However, Brooks supplies a very thorough and complete summary himself in chapter 18. It seemed a shame not to put it to good use, since it captures some of the nuances of writing computer programs in 1975 that my notes do not.
I provide my own highly condensed summary of the essay No Silver Bullet (Chapter 16), in whichBrooks argues that "there is no 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."
Even if you're not interested in reading the book, I would suggest this essay for anyone who works in software engineering. Specifically for Brooks' defintion of essential and accidental tasks and his discussion on why software engineering is inherently difficult.
The following is text from chapter 18 of The Mythical Man-Month by Frederick Brooks:
Software engineering is composed of two types of tasks: essential and accidental. Essential software engineering the process of fashioning logic into conceptual structures that compose the abstracted machine that is the software. Accidental tasks are all the things necessary to represent the essential byproduct in programming languages and mapping this onto machine languages within space and speed constraints.
Essential work is exactly that because it cannot be reduced. The essence of software is the totality of the various data, algorithms, invocations, etc., and all their relations to each other. This construct is entirely abstract—it would remain the same regardless of the infinite number of ways it could be represented through different implementations. Brooks states:
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation... If this is true, building software will always be hard. There is inherently no silver bullet.
So, what are the characteristics of software's essence that define it as such?
If we are to achieve order of magnitude improvements in building software, we must attack the essential tasks. What options do we have available to us?
"A team of two, with one leader, is often the best use of minds. [Note God's plan for marriage.]↩