The Mythical Man-Month book club questions

1. 1.

   Brooks's Law was formulated in the 1960s and remains accurate in 2026. What does that persistence tell you about the nature of software development versus other engineering disciplines?

2. 2.

   The second-system effect predicts disaster for the engineer's second project. Have you witnessed this pattern — in software or elsewhere — where success on a first project led to fatal over-ambition on the second?

3. 3.

   Conceptual integrity requires a single coherent vision. In a world of distributed teams and democratic decision-making, is that kind of concentrated authorship achievable? What does it cost?

4. 4.

   Brooks says to plan to throw one away — to treat the first implementation as a prototype. Where in your own work do you build this kind of exploratory learning into your plans?

5. 5.

   He argues that small teams of very capable people outperform large teams of average people. What organizational pressures prevent companies from building exclusively that way?

6. 6.

   'No Silver Bullet' was published in 1986. In the forty years since, we've had object-oriented programming, agile, DevOps, and now AI coding assistants. Does any of it falsify Brooks's claim?

7. 7.

   Brooks's experience was with hardware-constrained mainframe software of the 1960s. How much of his analysis transfers to modern web services, machine learning systems, or mobile applications?

8. 8.

   He distinguishes between essential complexity (the inherent complexity of what the software must do) and accidental complexity (complexity introduced by the tools and methods used). How does that distinction map onto a project you've worked on?

9. 9.

   Documentation is consistently under-resourced in software projects. What would change if teams treated documentation as core work rather than a debt to pay off later?

10. 10.

    The surgical team model concentrates work on star performers. What does that do to the development of less experienced team members?

11. 11.

    Schedule estimation failure is a recurring theme in the book. Why do software teams consistently underestimate, and what interventions actually help?

12. 12.

    Brooks made these observations managing one of the most complex software projects of the 1960s. What has he gotten most right and most wrong, looking at contemporary development?

How to run the discussion

• Pick six to eight, not all of them. An hour of real discussion covers fewer questions than anyone expects, and racing the list is what makes a book club feel like homework.
• Open with what people noticed, not what they concluded. Asking for a verdict first hardens opinions before anyone has heard each other.
• Let the disagreement run. The questions below that split a room are the ones worth the time; the ones everyone answers the same way can be skipped.
• Ask the quiet person a specific question. A direct, narrow question is far easier to answer than an open invitation to contribute.