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.
Essay 13 reply (October 04, 2015) …
The Whole and the Parts
Masterpieces! The tar-pit picture on the front cover of The Mythical Man-Month and the introduction to this chapter. Brooks combines a picture of Mickey Mouse as the wizard in Fantasia (The Walt Disney Company) and a profound quote from Shakespeare, King Henry IV, part 1.
“I can call the spirits from the vasty deep.
Why so can I, or so can any man; but will they come when you do call for them?”
This quote rings true across many disciplines; for technology, this quote and image is as fun today, as it was 40 year ago when Brooks was writing.
Essay 14 reply (October 25, 2015) …
Hatching a Catastrophe
Thomas, excellent analogy about frogs in boiling water. Brook’s memorable line “How does a project get to be a year late? … One day at a time.” has been a favorite of mine, my whole career.
This essay should be read by every Project / Program Manager, it is a classic.
On page 161, Brook’s calls what today we would call the Program Management Office an “irritant”, but tells us an A. M. Pietrasanta was able to run an effective PMO. I wish Brook’s would have written details around this remarkable accomplishment.
Essay 15 reply (November 01, 2015) …
The Other Face
Roll your eyes, this (documentation) isn’t a very exciting subject for most.
I had to comb this chapter a couple of times to find some useful tips from Brooks; unlike the previous chapters, where usefulness and interesting information just jumps out.
Are you using a standard that is not being used as intended?
Flow charting was such a standard practice. Mandated as a deliverable when I started my technology career.
p. 168 “Many shops proudly use machine programs to generate this “indispensable design tool” from the completed code.”
Flow charting back then meant documenting the entire program flow. Flowcharts are a great teaching tool and also a good visual design tool when used informally (paper and pencil, and high-level). But formally replicating the exact code logic is a waste of time.
I doubt if anyone consulted independent flow charts more than once. Why? Because they could not be trusted as a source-of-truth, but source-code has always been a trusted source-of-truth.
Any documentation extracted from the source-code can be trusted (assuming reliable software). Brooks does discuss “self-documenting programs” and I am sure Brooks became a fan of Javadoc. Wait, perhaps Brooks writing in this chapter helped influence the creation of Javadoc.
Essay 16 reply (November 08, 2015) …
No Silver Bullet – Essence and Accident In Software Engineering
I am no longer in re-read territory; I read the original publication and this chapter was published 11 years after.
In 1986, IBM’s mainframe dominance that Brooks started is now eroding with departmental computers from the likes of HP, Dec, Sun, and even IBM.
The era of the PC was in full swing, IBM PC clones abound running Microsoft’s MS-DOS, Apple’s MacIntosh has entered the market, Byte magazine is in its heyday, and the HTTP protocol has yet to-be invented.
As Thomas states above, this essay is the longest yet. I wonder if Brook’s continued career as the Computer Science Chair at the University of North Carolina (Chapel Hill) has influenced his writing style. I like the earlier chapters succinct style better.
And as Thomas infers above, there are many seeds of Agile written about in this essay.
Essay 17 reply (November 15, 2015) …
No Silver Bullet, Refired
Agree, Brook’s target audience has definitively changed in this chapter from the the practitioner to academia. It reminds of the director cuts you find on some DVDs, most viewers are only interested in the full feature movie.
Brook’s is asking and answering a very important question: what in software development has improved and not improved so much over the last 20 years?
I want to focus my response on an area Brook’s wrote about in the previous chapter and one that I currently wrestle with.
p. 199 “The hardest single part of building a software system is deciding precisely what to build.”
Some use Lean techniques in software today to discover the right thing in software to build.
SPaMCAST 342 – Gorman, Gottesdiener, Discover to Deliver Revisited
discusses this subject and is an excellent Podcast to re-listen to.
PMI is now offering training and certification as a “Professional in Business Analysis” (PBA).
During “The Mythical Man-Month” time period (20 years), the recognition of “What to build?” emerges as an equally important question as “How to build it?”.
Essay 18 reply (December 06, 2015) …
Mythical Man-Month After 20 Years
Thank you Thomas for choosing
“The Mythical Man-Month” and running with it!
The graphics and quotes at the beginning of each essay are always interesting. This essay begins with …
“I know no way of judging the future but by the past.” Patrick Henry
“You can never plan the future by the past.” Edmund Burke
Brook’s is back in form with this long and thoughtful essay.
As Thomas states above; this re-read was insightful to today’s world, we either learn or re-learn from this re-read experience.
For me during this re-read, I paid a little more attention to Brooks the man. I learned Brooks, besides being very perceptive and a good writer, is also a person of high-integrity, religious, and a computer scientist above being a manager.
I also learned through Amazon recommendations, that Brooks has another interesting book patterned after the “The Mythical Man-Month” which joins my already crowded book-list – “The Design of Design: Essays from a Computer Scientist” (copyright 2010).