Re-Read Saturdays: HTMA (part-2)

Re-read of the book
“How To Measure Anything (Finding the Value on ‘Intangibles’
in Business” (3rd edition) by Douglas W. Hubbard

Responses to Thomas Cagley’s re-read Saturday blog posting series.
I am posting my responses here, before a reply over there (chapter by chapter).

Part-1:  key concepts are what are measurements, why measure, what is risk, choosing what to measure (Chapters 1 – 7).

Part-2 (this post) is about the rest of the book, chapters 8 – 14 of the re-read.

Chapter 8:  The Transition: from What to Measure to How to Measure

The title of this chapter (The Transition: from What to Measure to How to Measure) is perfect for moving forward into part-2 of HTMA.

Hubbard summarizes what we can do to improve our measurements at the end of the chapter (pages 195 – 195) — (1) Work through the consequences, (2) Be iterative (yes! sounds familiar), (3) Consider multiple approaches, (4) What’s the really simple question that makes the rest of the measurements moot, and (5) Just do it.

My Notes from Chapter 8

  1. (p. 176-177) 6 questions to help determine the measurement methods
  2. (p. 178-179) 7 measurement instruments
  3. (p. 181) Decompose it (definition)
  4. (p. 183) Decomposition effect
  5. (p. 187) Some basic methods of observations
  6. (p. 190) Quick Glossary of (Measurement) Error
  7. (p. 193) A Few Types of Observation Biases
  8. (p. 194) Chose and Design the Instrument


Chapter 9: Sampling Reality How Observing Some Things Tells Us About All Things

There is a lot of information in this chapter.  Hubbard’s narrative discussing how to measure the number of fish in a lake (p. 214 – 215) helps me understand how this book lives up to its title.

My Notes from Chapter 9

  1. Mathless 90% CI, p. 211 Exhibit 9.4
  2. See relations in the data, p. 236  Examples of Correlated Data
  3. p. 242  The tw0 biggest mistakes in interpreting correlation.
    1. Correlation proves causation
    2. Correlation isn’t evidence of causation

Chapter 10:  Bayes:  Adding to What You Know Now

p. 247  “One of the key assumptions in most introduction-to-statistics course is that the only thing you ever knew about a population are the samples you are about to take.  In fact, this is virtually never true in real-life situations.”

p. 248 “Bayes’ theorem is simply a relationship of probabilities and “conditional” probabilities. …

p. 258 the Instinctive Bayesian Approach

p. 262 Exhibit 10.5 Confidence versus Information Emphasis

p. 264 Peter Tippett overcoming the “all things must be done” thinking that prevents measurements.

P. 276 “The Lessons of Bayes” (summary)

Chapter 11:  Preference and Attitudes:  The Softer Side of Measurement

The hypothetical utility curves helps with subjective trade-off evaluations (pages 300-301).

Example:  how does the performance of software team completing on-time at 99% with a 95% error-free rate compare with another software team completing on-time at 92% with a 99% error-free rate?  Check the organization’s utility curve for this trade-off.

My Notes

  1. Stated preferences versus Revealed preferences … Lean thinking
  2. This chapter has some good tips about designing surveys that can help measure and reduce uncertainty.
  3. p. 291 correlate subjective responses with objective measures (see Measuring Happiness)

Chapter 12:  The Ultimate Measurement Instrument:  Human Judges

Very good chapter notes!

Adding to (p. 325) “The Big Measurement Don’t – Above all else, don’t use a method that adds more error to the initial estimate.”, Hubbard warns us about using arbitrary scores (e.g., a scale of 1 – 5).

(p. 327) “I’ve always considered an arbitrary score to be a sort of measurement wannabe.” and then proceeds to list six reasons to support his statement.

Chapter 13:  New Measurement Instruments for Management

This chapter is about new ways of measuring using resources on the internet:  two books called out are

  1. Eric Siegel “Predictive Analytics:  The Power to Predict Who Will Click, Buy, Lie, or Die”
  2. Hubbard’s third book “Pulse:  The New Science of Harnessing Internet Buzz to Track Threats and Opportunities”

Pages 351 – 352, Hubbard summarizes four Subjective Assessment Methods to Prediction Markets, including what Hubbard discussed in this chapter, the Prediction Market.  The other three from previous chapters include (1) Calibration Training, (2) Lens Model, and (3) Rasch Model.

Thank you Thomas for selecting Commitment – Novel About Managing Project Risk by Olav Maassen, Chris Matts, and Chris Geary (Illustrator)  as the next re-read.  It will be a quick and fun read, and help any project leader.

My 90% calibration estimate to complete this re-read is 2 – 3 weeks, even though it is 216 pages (hard cover edition); the pages turn fast!

Chapter 14:  A Universal Measurement Method: Applied Information Economics

I like the summary of this book which comes from question #23 (Chapter 14)  in the HTMA Workbook, and I am quoting both the question and answer …

Summarize six points the author makes about the AIE philosophy.

  1. If it’s really that important, it’s something you can define.  If it’s something you think exists at all, it’s something you’ve already observed somehow.
  2. If it’s something important and something uncertain, you have a cost of being wrong and a chance of being wrong.
  3. You can quantify your current uncertainty with calibrated estimates.
  4. You can compute the value of information by knowing the “threshold” of the measurement where it begins to make a difference compared to you existing  uncertainty.
  5. Once you know what it is worth to measure something, you can put the measurement effort in context and decide on the effort it should take.
  6. Knowing just a few methods for random sampling, controlled experiments, Bayesian methods, or even merely improving on the judgements of experts can lead to a significant reduction in uncertainty.

Hubbard last paragraph in the HTMA book tells to how to start applying this knowledge (p. 385) “… and the practical cases described make you a little more skeptical about claims that something critical to your business cannot be measured”.

Last words about HTMA

Nice summary of HTMA Thomas!

This material, like running, takes more than just reading about it. It takes practice / training, and there are supplemental Excel worksheets online to study.

One of my favorite parts of HTMA is where Hubbard explains how to estimate the number of fish in a lake (p, 214 – 215).

The bridge: HTMA briefly discusses options and how “real” Options are over-used (p. 383-384). One of the themes in the next book up “Commitment…” is “real” Options. It will be interesting to compare notes.



Re-Read Saturdays: HTMA (part-1)

Re-read of the book
“How To Measure Anything (Finding the Value on ‘Intangibles’
in Business” (3rd edition) by Douglas W. Hubbard

Responses to Thomas Cagley’s re-read Saturday blog posting series.
I am posting my responses here, before a reply over there (chapter by chapter).

Part-1 (this) covers chapters 1 -7 of the re-read
Part-2 covers chapters 8 – 14 of the re-read

Chapter 1:  The Challenge of Intangibles

This is not a re-read for me, but two books I have read this year have referenced Hubbard’s “How To Measure Anything”, so I am excited to get into this material and this re-read series.

In Hubbard’s own words “measure what matters, make better decisions” which also could have been the title for this book.

And on page 7:  “Upon reading the first edition of this book, a business school professor remarked that he thought I has written a book about some esoteric field called “decision analysis” and disguised it under a title about measurement so that people from business and government would read it.  I think he hit the nail on the head.”

The book “Lean Enterprise” (O’Reilly) makes references this book and I found a quote which I think echos Hubbard’s thinking.  Chapter 5 (Lean Enterprise), a quote from another book “Lean Analytics” … (the quote)
“If you have a piece of data on which you cannot act, it’s a vanity metric”.


Chapter 2:  An Intuitive Measurement Habit:  Eratosthenes, Enrico, and Emily

This is the motivation chapter, where Hubbard provides three different, inspirational, and instructive examples of measurements by Chapter 2’s named heroes — Eratosthenes, Enrico, and Emily.

From Eratosthenes, we learn “He wrung more information out of the few facts he could confirm instead of assuming the hard way was the only way.” (p. 17).

From Fermi Enrico, we learn “start to ask what things about it you do know” (p. 19).

From Emily Rosa (and Hubbard), we learn a stated benefit should have something tangible associated with it — “If the therapists can do what they claim, then they must, Emily reasoned, at least be able to feel the energy field.” {in my experiment} (p.21).

Hubbard’s own example:  “If quality and innovation really did get better, shouldn’t someone at least be able to tell that there is any difference?” (p. 24)

Hubbard challenges us and sets up the coming chapters:  “Usually things that seem immeasurable in business reveal themselves to much simpler methods of observation, once we learn to see through the illusion of immeasurability.” (p. 25)


Chapter 3:  The Illusion of Intangibles:  Why Immeasurables Aren’t

There is so much valuable information in this chapter about measurements and defending measurements from the doubters.

One other interesting thing I did learn from footnote #14, Mark Twain did not originally come up with “Lies, Damned Lies, and Statistics”, although as Hubbard points out, Mark Twain did help popularize this saying.

My notes from Chapter 3:

  1. Claude Shannon (Electrical Engineer, Mathematician) – Information Theory and how it applies to measurements (p. 31)
  2. Stanley Smith Stevens (Psychologist) – Scales of Measurement (p. 33)
  3. There is a Measurement Theory (p. 34)
  4. Bayesian Measurement, reduce uncertainty of the observer (p. 34)
  5. Measurement Clarification Chain (p. 39)
  6. The Power of Small Sample:  The Rule of Five (pages: 42 -43)
  7. Usually, Only a Few Things Matter — But They Usually Matter a Lot (p. 49)
  8. Paul Meehl (Psychologist) – “showed simple statistical models were outperforming subjective expert judgements in almost every area of judgement he investigated including predictions of business failures and outcomes of sporting events.” (p. 51)
  9. Defending Measurements (e.g., “this measurement can not apply to this unique situation”)
    1. The Broader Objection to the Usefulness of Statistics (p. 52)
    2. Ethical Objections to Measurement (p. 55)
  10. Four Useful Measurement Assumptions (p. 59)
  11. Hubbard ends Chapter 3 with “Useful, New Observations Are More Accessible than You Think” (p. 65)


Chapter 4:  Clarifying the Measurement Problem

Thomas your summary of Chapter 4 is very thorough!

Did you know there is a companion HTMA workbook for the HTMA 3rd edition book we are re-reading?

One question from the workbook I missed is the concept of “false dichotomy”  (see p.  75 in the HTMA book) when exploring a decision to measure.

Make sure the decision you are supporting through a measurement is not a false dichotomy.  That is, not a feasible alternative.  Typically, as Hubbard explains “Yes/no choice between two extremes” or as I think about it, a “Mom and apple pie” decision statement.

My example:  suppose your decision is whether you should exercise or not.  Drill down on that decision statement and define what type of exercise program you should engage in instead (e.g., gym workouts, running, bike riding, hiking) and then figure-out the measurement to support that decision.

Hubbard’s examples were (1) clean drinking water (book) and (2) worker safety (workbook).

My notes from Chapter 4:

  1. 5 point process (p. 71) – starting with “What is the decision this measurement is supposed to support?”
  2. False dichotomy (p. 75)
  3. Requirements for a Decision (p. 78)
  4. If you understand it, you can model it (p. 80)
    1. decomposition to improve estimates (p. 81)
  5. Definitions of Uncertainty and Risk (p. 84)  **** (4 stars!)
  6. Clarified Decision example – IT Security at the VA – (pages 84 – 90)


Chapter 5:  Calibrated Estimates How Much Do You Know Now

I learned a new skill reading this chapter and practicing the sample calibration tests.

My approach for using the calibration tests in this chapter and in the appendix of the book, is to take 5 questions at-a-time.  That is, if you are time challenged.

I was happy that my 90% range did cover the actual value of the average percentage of Design in Software projects.

And I also recommend the Feakonomics podcast titled “How to Be Less Terrible at Predicting the Future” (January 14, 2016)

My notes from chapter 5

  1. Calibration is a skill that can be learned.
  2. Work on the low-end and high-end as two separate questions.
  3. Go wide enough to be more than 90% confident and bring in your estimates to at your 90% interval, on each end.
  4. For subjects you know nothing about, do a little research first.
  5. Practice.


Chapter 6:  Quantifying Risk through Modeling

I have drank the kool-aid on this stuff.  Forecasting using Monte Carlo simulation is a much better way.

Author Daniel S. Vacanti also has some words to say about this in his book “Action Agile Metrics for Predictability“, and Vacanti’s book also references Hubbard’s HTMA book.

Hubbard talks about selecting the correct probability distribution for you Monte Carlo simulation.  Vacanti states you need worry about this if you have the data.  And Vacanti’s book is all about collecting the data for processes (incoming and outgoing).

I use this exact approach to collect data about the scrum sprint processes.  The clock starts when a user story is accepted into a sprint and the sprint begins.  The clock ends when either that user story is deployed into production, postponed, or returned into the Backlog.  Start – Stop cycle-time is what I report on, but I also collect two other intermediate events – dev-complete and business accepted to help figure-out how-to reduce the end-to-end cycle-time.

I then use this data to forecast using Monte Carlo simulations with the help of Daniel S. Vacanti’s Actionable Agile online tool.

My Notes from chapter 6

  1. p. 123, “if a measurement matter to you at all, it is because it must inform some decision that is uncertain and has negative consequences if it turns out wrong.
  2. How NOT to quantify risk – low, medium, high; write a check to an insurance company with the amount “medium”.
  3. Not enough to just read this chapter, go get the books worksheets at the HTMA companion web-site and examine them.
  4. The book’s companion workbook challenges you not just read this but to work with material and develop the skills needed to use these concepts confidently.
  5. p. 134, “So we don’t ask whether a model lacks some detail.  If course it does.  What we ask is whether our model improved on the alternative model by enough to justify the cost of the new model.”
  6. p. 138 – 139, Exhibit 6.7 A Few Monte Carlo Tools
    (Also, note professor Sam Savage (Stanford) has a tool and Hubbard wrote about Professor Savage work (p, 136 – 137) “how-to institutionalize the whole process” and having a CPO = Chief Probability Officer.
  7. p. 140, “Risk Paradox  If an organization uses quantitative risk analysis at all, it is usually for routine operational decisions.  The largest, most risky, decisions get the the least amount of proper risk analysis.”  (e.g., IT investments)


Chapter 7:  Quantifying the Value of Information

What is actually worth measuring?

How many times have we been part of a project where the convenient measurement is the focus of all the attention and we intuitively know this measurement is a proxy measurement at best.

This chapter gives the reader willing to study and work-at-it a method to figure out what to actually measure that will make an economic difference.

My Notes from Chapter 7

  1. Must work the accompanying Excel worksheets to develop this skill.
  2. (p. 145) re-read the “The McNamara Fallacy”, it captures what goes wrong with many measurement programs.
  3. (p. 149) Value of Information formula
  4. (p. 157) Zilliant: A Pricing Example (case study) …
  5. (p. 160) The Value versus Cost of Partial Information graph
  6. (P. 162) key concept – A Common Measurement Myth — when there is a lot of uncertainty, a lot of data is NOT required.
  7. (p. 167) The Measurement Inversion (what is really important to measure, and what is not) … go to top of page 168 for a summary
  8. (p. 171 – 172) Part-1 summary

End of part 1 of re-read of HTMA (How To Measure Anything), chapters 1 through 7




Mythical Man-Month Re-read Replies (part 3 of 3)



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 replies 13 through 18 I made .
My replies posts of Part-1 and Part-2 are already out.

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
followed by
“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).


End of Part-3 (of 3),  contains the replies from essays 13 through 18
Part-1 contains the replies from essays 1 through 6
Part-2 contains the replies from essays 7 through 12

Mythical Man-Month Re-read Replies (part 2 of 3)



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 replies 7 through 12 I made .
You can anticipate my next wordpress Post and Part-1 is already out.

Essay 7 reply (August 26, 2015) …
Why Did the Tower of Babel Fall?

Reduce the need for communication: Dr. Brooks states the D. L. Parnas has proposed a radical solution (back in 1970s), information hiding in modular programming. A person doesn’t need to know everything, (p. 78) “the programmer is most effective if shielded from, rather than exposed to the details of construction of the system parts other than his (her) own”.

We see this everyday; I can know the time without knowing how the clock works. I can drive a car without knowing how the motor works. I can “leave a reply” without knowing how the web-site works.

My favorite quote from this chapter (p. 80): “Thinkers are rare; doers are rarer; and thinker-doers are rarest.”

Essay 8 reply (August 30, 2015) …
Calling the Shot

Thomas, you nailed this chapter.

“Prediction is very difficult, especially if it’s about the future.”
– Nils Bohr

I like Brooks good-enough estimating rules for his time / situation (p. 93),
“My guidelines in the morass of estimating complexity is that compilers are three times as bad as normal batch application programs, and operation systems are three times as bad as compilers.”

Essay 9 reply (September 06, 2015) …
Ten Pounds in a Five–Pound Package

Thomas to amplify on #3 above and something I see a lot. Brooks (p, 100) “Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager.”

From Lean, we learn the words “may well be” can be replaced by “is”. And for that matter, “programming manager” can be replaced by “everyone”, certainly everyone that strives to provide leadership.

Another quote I like (p. 98) “Like any cost, size itself is not bad, but unnecessary size is”.

Essay 10 reply (September 13, 2015) …
The Documentary Hypothesis

It was the Brook’s reference of Conway’s Law (p. 111), which I was researching months ago, that sparked my interest in re-reading The Mythical Man-Month.

p (112) “But only the written plan is precise and communicable. Such a plan consists of documents on what, when, how much, where, and who.”

Brook’s must have been thinking about project management / project execution when he wrote this. The “why” is missing. We all, on occasion, fall into the trap of assuming the “why” is understood. Or worse, telling people to “just get it done”.

Essay 11 reply (September 20, 2015) …
Plan to Throw One Away

As Thomas states above, Brooks understood the nature of software development and foreshadowed much of what we now call agile.

Brooks also discussed software defects in this chapter, see figure 11.2 (p. 121) “Bug occurrence as a function of release age”

“These things get shaken out, and all goes well for several months. Then the bug rate begins to climb again. Miss Campbell believes this is due to the arrival of users at a new plateau of sophistication”

Essay 12 reply (September 27, 2015) …
Sharp Tools

There are many ideas to think about this week. I will respond to something that wasn’t around when The Mythical Man-Month was written and take a broader definition of software tools – open-source.

Specifically the open-source that finds its way into the software product / solution being delivered. Security concerns do need to drive the list of software tools / components selected to a smaller and vetted list.

1) Reduce the products attack surface
2) More focused response when security vulnerabilities are found for the organization

End of part-2, contains the replies from essays 7 through 12
Part-1 has replies from 1 through 6 and
Part-3 has replies from 13 – 18

Mythical Man-Month Re-read Replies (part 1 of 3)



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”.

End of part-1, contains the replies from essays 1 through 6
Part-2 has replies from essays 7 through 12 and
Part-3 has replies from essays 13 – 18