23 September 2018

The Mythical Man-Month: A Review

I picked up Frederick P. Brooks Jr.'s The Mythical Man-Month from the library on the advice of my friend Judson, who called it "required reading for anyone in the software profession." I'm so glad I did! This is easily my favorite piece of writing about computer engineering.

(Note: All my page numbers come from the 20th anniversary edition, linked above.)

In the very first chapter, "The Tar Pit," Brooks gives a compelling list of reasons why programming is rewarding. He concludes it with:
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.) (p. 7)
Brooks writes clearly, intelligently, and occasionally very beautifully about the craft of software development. Another example of his wisdom wrapped in elegant prose comes later in the same chapter:
For the human makers of things, the incompleteness and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, "working out" are essential disciplines for the theoretician (p. 15). 
Although it has some lovely passages, the book is not principally a collection of creative essays about programming. Rather, it is Brooks's attempt to identify and correct some of the common problems that software development professionals go through. It contains some really good advice and valuable cautionary statements. For example, in the chapter that gives the book its title:
Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable (p. 16, emphasis in original).
This is excellent advice for programmers, but even better advice for project managers and upper management in technology companies. Brooks has valuable ideas, too, for technical writers:
English, or any other human language, is not naturally a precision instrument for [definitions of system architecture]. Therefore the manual writer must strain himself and his language to achieve the precision needed. An attractive alternative is to use a formal notation for such definitions (p. 63).
And again, for testers:
The project manager's best friend is his daily adversary, the independent product-testing organization. This group checks machines and programs against specifications and serves as a devil's advocate, pinpointing every conceivable defect and discrepancy. Every development organization needs such an independent auditing group to keep it honest. 
In the last analysis the customer is the independent auditor. In the merciless light of real use, every flaw will show. The product-testing group then is the surrogate customer, specialized for finding flaws. Time after time, the careful product tester will find places where the word didn't get passed, where the design decisions were not properly understood or accurately implemented. For this reason such a testing group is a necessary link in the chain by which the design word is passed, a link that needs to operate early and simultaneously with design (p. 69).
Some of the documentation sections also have important thoughts for UX designers:
A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous definitions all exist to make intention clear to the dumb engine.
But a written program has another face, that which tells its story to the human user. For even the most private of programs, some such communication is necessary; memory will fail the author-user, and he will require refreshing on the details of his handiwork.
I really love Brooks's concrete examples. To illustrate the role of upstream dependencies in planning, he writes that "The bearing of a child takes nine months, no matter how many women are assigned" (p. 17). Later, he gives the extended example of an omelette when discussing why it's important not to deliver a product before it's ready (p. 21).

For all of its usefulness, this isn't a perfect book. It was written in 1975, so many examples and ideas are outdated or irrelevant.

For instance, we don't need a pool of typists to compile the code changes from the previous day and bind them in a book for distribution to all programmers. Shared version control has thankfully made that practice a thing of the past.

There are also lengthy treatments of sharing processing time, dumping memory to printouts for debugging, and low-level hardware and software concerns that modern programmers simply don't have to deal with anymore.

For this reason, some reviewers have complained that the book is so outdated as to be of very little use. I have a couple of responses to this:

  1. Many of the technological advances we enjoy today are owing to people like Brooks, who highlighted the difficulty of the status quo. This book is such a fundamental building block in our field that it has almost certainly encouraged the growth of IDEs with integrated debuggers, shared source control repositories, and so on.
  2. Even though some parts are not relevant today, they still serve a valuable historical purpose. In addition, they often have analogs to problems we face in programming today.
Another drawback that some reviewers have noted is Brooks's very traditional mindset. For example, he makes no effort to consider the existence of women in any role other than members of the secretarial pool. The theoretical programmer always gets "he/him/his" pronouns. While this is problematic in our modern culture, it is perhaps relevant that in Brooks's time, very few women were programmers. Thus, his assumption that they would be male is at least statistically defensible, if not ideologically so.

I think this book is worth a read for anyone in the software development industry. Project managers and people managers would find it especially useful, I think. Most of the less useful and applicable portions are later in the book, so I'd advise reading the first three or four chapters pretty carefully, then skimming the remainder if you'd prefer.

John 1:10-11

One of my favorite reality TV shows is Undercover Boss. I love seeing the CEO of a large company face the consequences of his choices and corporate strategies. I love how he interacts with his employees and discovers that their jobs are more difficult than he imagined. But most of all, I love it when employees throw shade at upper management with him right there in the room. That's good TV, my friends.

In this passage, Jesus is the ultimate Undercover Boss:
He was in the world, and the world was made through Him, and the world did not know Him. He came to His own [or own things, possessions, domain], and those who were His own did not receive Him. (John 1:10-11, NASB)
The Beginning: All is nothingness, an unformed chaos. A mysterious breath hovers over the surface of dark waters.

A disembodied Voice speaks. Light illumines the darkness. The light is constrained to a pattern of behavior: Day; Night; goto Day;

The Voice speaks again. The shapeless void is distinguished into wet water, grainy sand, loamy earth. The sky is divided from the earth and the sea from the land. The world begins to take form, to be distinct from the universe around it.

And so goes creation: The Voice speaks, bringing order and beauty from the void, and it is very good.

John's claim is that Jesus, housed in a frail meatflesh body that defecates and stubs its toes and sometimes has a bad cough, is the very embodiment of the Voice that wove the world into its beautiful being.

More than that, Jesus is the same eternal God who made a deal with Abraham: Follow me, and I will make you a great nation. Your wife may be barren, but that won't stop me from giving her descendants numbering like the stars in the sky or the grains of sand on the seashore. (See Genesis 12-17.)

So here comes this Jesus into the land of Israel, to the very descendants of Abraham, Isaac, and Jacob. As he walks, his feet grow dusty with the dirt he formed in the beginning. He is walking among people who are the very grains of sand, the skystars he promised to Abraham.

And yet, like the hapless CEO of Burger Behemoth, failing to keep up with the fry timers in the back of the restaurant, Jesus is not seen for who he is. Many reject him, especially those who have a lot to lose from any disruption to the status quo.

But, as we'll see in our next installment, there's a great reward for those employees who respond well to this Undercover Boss.