from Hacker News

The Bluffers Guide to the Mythical Man Month

by JazCE on 11/20/23, 8:54 AM with 89 comments

• by misja111 on 11/20/23, 9:51 AM

  This is a very shallow summary of the Mythical Man Month, and it leaves out at least one concept that the book is most (in)famous for: the '10 times programmer'. An excerpt:

  > In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one.

  Brooks did mention some other really useful concepts that are still very valid today: 'No silver bullet' and 'The second-system effect'. These should have been mentioned as well.

• by paddy_m on 11/20/23, 5:41 PM

  I am surprised that there's less mention of Brook's proposed team organization, a team of 10 led by a surgeon. The team is supposed to work on a single project. Every org I have seen has much smaller teams with much more individual responsibility and attendant coordination problems.

  I can see shaving 1-3 people off of Brook's ideal team (we don't need a secretary to type anymore, PM's that organize projects at the behest of a technical leader are effective).

  What I have seen over and over is, whoever writes the most code tends to get the most power in an org. Whoever is delivering features quickly gets power. This kind of works, but these coders frequently leave poorly thought out architecture that is hard to extend.

• by sizzzzlerz on 11/20/23, 3:21 PM

  While Brooks' book is nominally about software processes, in my career of over 40 years, I found it to be applicable to just about every engineering discipline to which I played a part. I read this book back in the 70's and then every 10 years or so and I never failed to learn something new from it. I just wish the managers and companies I worked for would have applied these lessons.

• by danielovichdk on 11/20/23, 7:40 PM

  The Mythical Man Month is great. What makes it great, is that it circles around how important everything but code is, in any professional software development progression.

  I would argue that it should be the bible for every manager that are managing engineers. They should study it thoroughly and all the literature it touches and mentions.

  The best book I have read on software development by far.

• by lordnacho on 11/20/23, 9:45 AM

  It's always a surprise to know how far back good ideas actually go. Brooks figured out all this stuff in the 70s, pretty much as soon as it was possible for someone to have done this type of work and written a book about it.

  Reminds me of Adam Smith's writings about the nascent factory economy, and perhaps ancient philosophers as well.

• by AdamH12113 on 11/20/23, 7:19 PM

  The concept of "conceptual integrity" is one of the most useful things I've ever learned. The tension between conceptual integrity and things like group-based communication and requirements-gathering (what one might call "representativeness") seems to me to be a foundational issue not just in software development but in human civilization as a whole.

• by jcmeyrignac on 11/20/23, 11:08 AM

  This is nothing new. In 1913, Max Ringelmann measured the effort of individuals when working in a group. The results are impressive: https://gallica.bnf.fr/ark:/12148/bpt6k54409695.image.f14

  A group of 8 persons provides the same amount of work as 4 individuals.

• by ewst on 11/20/23, 1:26 PM

  > As more people are added to a project, the complexity of communication increases exponentially.

  Doesn't it increase by n^2? as per the picture with the graphs?

• by rco8786 on 11/20/23, 1:14 PM

  I've always had a little bit of a gripe with how the "communications complexity" is presented here. As if the only way to communicate on a team is to have everyone stand in a circle and yell at everyone else.

  In reality, there is very often opportunity to take 1 project with ~3 engineers, and break it into 2 smaller projects each with ~3 engineers and run them mostly in parallel. Do your best to isolate those projects, but have a point of contact (EM, PM, tech lead) between the two teams to coordinate whatever dependencies are unavoidable, etc.

  You'll notice, that this is just a smaller microcosm of how every company is actually structured anyway. There's still diminishing returns, but most people on the team never need to communicate directly with people outside of their project.

• by fassssst on 11/20/23, 5:36 PM

  The book only takes like an hour to read you know.

• by bernardlunn on 11/20/23, 10:30 AM

  I read it in the 1970s as a youngster, now retired, brilliant then and now.

• by monoscient on 11/20/23, 9:02 PM

  I'm so sorry but I read it as "the Mythical Moth Man" for a second

• by gjadi on 11/20/23, 1:46 PM

  Another aspect discussed in TMMM not present in this summary is the possible benefits of AI.

  Brooks says there can be some gains, but no silver bullet :)

  - As a Testing Agent that learns how the system behave and how to test it as the developers interact with the agent.

  - As a tutor, junior can learn from the knowledge of experts by interacting with the AI.

  - For "automatic" programming when the problem is characterized by few parameters, when there are many known solutions and good knowledge to select the correct solution.

  So far I've read about tutoring and automatic programming, but I haven't read about how to use AI to learn about the system and generate tests.

• by pie314isi on 11/20/23, 10:37 AM

  once, when complaining to a colleague about our workplace and their hiring and staffing idiosyncrasies, I quipped "I should give <manager> a copy of TMMM". My colleague, without missing a beat said "You should give him two copies so he can read it faster"