Bookshelf Classic: The Mythical Man-Month

-
Cover for The Mythical Man-Month 20th Anniversary Edition
More than 250,000 copies were printed, and yet, that was not enough to spare me countless programming and management fads.  So popular was this title that it earned a 20th Anniversary Edition and still, buzzwords like "pair-programming," "open workspaces," "test driven development," and "military style management" forced their way into my vocabulary.

Frederick P. Brooks, Jr., in 1964, managed the software side in the creation of the IBM 360 Mainframe Computer.  Working on the famed project also afforded him a view of the hardware management side, and by way of comparison, he noticed that no developments in software could, or ever would, improve productivity, reliability, and simplicity in the same way hardware improved with advances in electronics, transistors, and large-scale integration.  Noting Moore's law, Brooks writes "We cannot expect ever to see two-fold gains every two years." 

The essays in The Mythical Man-Month shed light as to why programming is hard to manage, but not in a guru-like manner.  Rather, Brooks writes from a position of humility.  Of the IBM 360 Operating System:

"... the product was late, it took more more memory than planned, the costs were several times the estimate, and it did not perform very well until several releases after the first."

The essays can be enjoyed in any order, and three have resonated with me.  Chapter 3 The Surgical Team describes why a balanced team matters and Brooks breaks it down with the diagram below:

Diagram of a 10-man programming team

He asks who is the surgeon and who are the nurses and anesthesiologists on a programming team, how is the work divided, and how does the group communicate?

Brooks found small teams very effective, but the challenge was scaling them up for a project as large as the IBM 360.  This was his thesis, and the remaining chapters discuss various  techniques at coordination and not succumbing to The Second-System Effect -- another of my favorite essays -- described in Chapter 5. There he writes "The second is the most dangerous system a man [or woman]¹ ever designs."  

An architect building his first system would be circumspect, given his inexperience and the unknowns.  He would be careful and restrained, and set aside bells and whistles for perhaps a subsequent release.  Not so with his second system, where ambition and hubris could blur, and where temptation would be high to incorporate functional ornaments, and to ignore changes in the technology landscape from when these features were first conceived.

How does an architect avoid the second system effect?  Brooks dryly responds "Well, obviously he can't skip his second system."  For specific measures, go read the essay for yourself.

Finally, I'd like to point out Chapter 16 No Silver Bullet which was added for the 20th Anniversary Edition.  Here, Brooks indulges in a wager of sorts, predicting "that a decade would not see any programming technique that would, by itself, bring an order-of-magnitude improvement in software productivity." 

Given that the Anniversary Edition was published in 1995 and it is now 2018, and given all the fads I endured in between, I'd say Brooks won handily.  Although an order-of-magnitude is a lot to ask in the software world, No Silver Bullet also tries to identify helpful and unhelpful trends.  Of the helpful group, Brooks was prescient regarding Agile Methodology, identifying two of its components: 
  1. Requirements refinement and rapid prototyping
  2. Incremental development -- grow, not build, software
Yes, Agile is a buzzword, but showing promise, it is not a fad. And like Agile Methodology, Brooks argues that the most important component to a software project is people rather than process.  Ultimately, bugs, core dumps, and blue screens do not respond to demands, death marches, or heroic measures.  They respond to competence and time.





    --
    ¹ [or woman] Consider this my humble contribution to the 50th Anniversary Edition



    Comments

    Post a Comment

    Popular posts from this blog

    MR2 Check Engine

    -
    Image
    Shown here is the 1991 Toyota MR2. Thanks to the mechanical skills of a family enthusiast, it purrs, growls, and turbo whistles like a dream.   My hardware ability doesn't go much further than oil changes. Rather, my expertise is in software, and I wrote an Android App (iOS version is in progress) to diagnose the flashes of the check engine light. This second generation MR2 predates the OBD2 connector, a standard used to diagnose engine, transmission, and emissions problems quickly and easily. Instead, we have a flashing check engine light which needs some deciphering, followed by a lookup in the service manual. Basically, you count flashes to arrive at fault code number. A short pause (~1.5 seconds) indicates the start of the next digit. A medium pause (~2.5 seconds) indicates start of the next fault code. And a long pause (~4.5 seconds) means the sequence has ended and will repeat. The video below corresponds to the codes 41 and 51. Using the the MR2 Check app and selecting the 3
    Read more

    Bookshelf: UNIX A History and a Memoir

    -
    Image
      A man page will give you, in black and white, specific information about UNIX. Brian Kernighan's new book adds color and depth about UNIX you won't find anywhere else. I'm not a gray beard (yet), but I imagine they would plow through the book knowingly, but at the same time, learn a few things. Those new to UNIX -- recent college grads or those experimenting with Raspberry Pi -- would be better off starting with Chapter 8 which describes more relatable events and the descendants of UNIX, including Minux and Linux. It's when they start to ask questions like "Where does UNIX come from?" and "Why is Gamora grep?" that they should start from the beginning: Bell Labs, 1969. Kernighan opens with a birds-eye-view of Murray Hill New Jersey, zooms in on the buildings, the offices, the significance of Center 1127, and offers a brief look at some of the key players there. As I progressed through the book, the two factors that made UNIX not just possible, bu
    Read more

    Bookshelf Classic: The C Programming Language

    -
    Image
    My first job had me programming in Microsoft BASIC for the IBM PC (DOS).  BASIC worked well enough, but its limitations were clear.  The language was interpreted and therefore slow.  More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement.  Anyone who has read Dijkstra knew  GOTO was a bad thing . Having learned a structured language in college ( PL/I ), using BASIC felt unnatural.  When a C compiler became available for the PC, I saw a chance to improve and modernize our software.  The problem was selling the idea -- a problem made harder because I wasn't fluent in C. "It would be a staffing problem.  Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager. The argument was strong as my knowledge of C was weak.  But I knew that C, by design, was a small language and thus easy to learn.  "It has about 30 keywords," I proffered to another manager. U
    Read more