Software Process and Measurement (SPaM Cast) podcaster, author, and Agile Consultant Thomas Cagley ran a re-read Saturday series on Dr. Fred Brook’s classic computer science book “The Mythical Man-Month“.
I replied to all 18 of Thomas’s Mythical Man-Month wordpress Posts.
Herein are the first 6 replies I made in my very first wordpress Post.
You can anticipate my next two wordpress Posts.
Essay 1 reply (June 28, 2015) …
The Tar Pit
The Tar Pit is a great metaphor for software projects and that hasn’t changed.
Page 4: (Large-system programming) “most have emerged with running systems — few have met goals, schedules, and budgets.”
Two things that have changed since Fred Brooks was developing IBM’s OS/360 product are
(1) The cost of hardware was more expensive than the cost of people; the cross-over point for many organizations was around 1975 when the “The Mythical Man-Month” first published.
(2) Specialization: computer programmers typically had much broader roles; design, coding, testing, deployment, and support. Wait, we are coming back to that model for teams (e.g., Amazon’s two pizzas teams).
Essay 2 reply (July 13, 2015) …
The Mythical Man-Month (same as the book title)
Fred Brooks is an excellent writer, many memorable quotes about software engineering and project management here, chapter 2.
One of my favorites found in the Gutless Estimating section (p. 21):
“An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices – wait or eat it raw, Software customers have had the same choices.”
And I will add, often still do.
Essay 3 reply (July 20, 2015) …
The Surgical Team
I learned a new word, desiderata, which is a Latin word meaning desired things.
I am glad software development teams are thinking about collaboration and self-organization now days, rather than Brook’s Surgical team concept. The key difference is that Surgical teams are performing an established procedure, whereas software teams are, in-part, exploring the best solution.
Essay 4 reply (July 26, 2015) …
Aristocracy, Democracy and System Design
I have to wonder, if somewhere along the way Steve Jobs read this chapter and took it to heart.
A great quote (p 43) “this ratio of function to conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design.”
And seeds of agile here too, p. 49, “three distinct phases: architecture, implementation, and realization. It turns out that these can in fact be begun in parallel and proceed simultaneously.”
Essay 5 reply (August 02, 2015) …
The Second-System Effect
A lot in this small chapter! This is the one chapter I do remember from early in my career. We always called the second-system effect the windmill effect, but that wording is not written in this chapter.
Take Brook’s advice for the Architect to the Builder (p. 54), and substitute Product Owner for Architect. This advice is golden.
I am not sure why Brook’s singles out the second-system (or the second release); I think this piling-on effect can happen anytime after the very first release. Limited iterations / time-boxes really helps thwart this human tendency.
Brook’s gives so many good examples in this chapter, where the second-system effect relates to the non-value delivered.
1) The release does not create as much value as everyone thought it would. (p. 55) “The operation set is so rich and profuse that only about half of it was regularly used.”.
2) There maybe some value in this release, but now the system is overly complex. Read Strachey review of the Stretch operating system (p. 56).
3) There is little or no value delivered because the system is solving an out-dated problem. (p. 57) “… it (linkage editor) is slower than most of the system compilers. The irony of this is that the purpose of the linker is to avoid recompilation. Like a skater whose stomach gets ahead of its feet, refinement proceeded until the system assumptions had been quite outrun.”.
Essay 6 reply (August 09, 2015) …
Passing the Word
In this chapter, Dr. Brooks again has some really good advice, but not so much about communication in large projects (pages 66 – 68, 5 short sections). Here Dr. Brooks writes in his large, IBM project context, pre-internet and when online terminal access was just emerging. Dr. Brooks would have loved to have a URL for FAQs, rather than to manage a paper-based, telephone call-log.
Interesting, and I remember this, the manual was the user interface.
Dr. Brooks reminds us again that requirements documentation should focus on the “what” and not the “how”. [And we know from agile, to include the “why” also]
(p. 62) “The manual must not only describe everything the user does see, including interfaces; it must also refrain from describing what the user does not see.”
(p. 65) “there are 30 different “curios” – side effects of supposedly invalid operations – that came into widespread use and to be considered as part of the definition. The implementation as a definition overprescribed; it not only said what the machine must do, it also said a great deal about how it had to do it.”
Today, we can substitute the word “hack” for the word Dr. Brooks used, “curios”.