Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bluffers Guide to the Mythical Man Month

codemanship.wordpress.com

Post reply on HN
Print view View original

31–40 of 95 posts

Re: The Bluffers Guide to the Mythical Man Month

#31

Post by verbify »

Cthulhu_ wrote: post #26
mindsuck wrote: post #25

Earlier quoted context omitted.

You believe every tech oriented person already knows everything there is in the book?

No, but most will at some point in their career hear about it in comment sections on HN and the like, or in many different forms hear the adage that adding more people to a project makes it later.

Many developers don't spend time on hacker news or even any of the similar forums. To be stereotypical, HN readers seem more likely to be young, working for FAANG in Silicon Valley, and not a middle aged sharepoint integration developer living in the Midwest (although obviously they are also on this site).

I've had developers who treated it like a job, did it, went home, and weren't interested in the Mythical Man Month (but intuitively knew some of these principles).

Re: The Bluffers Guide to the Mythical Man Month

#32

Post by rco8786 »

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.

Re: The Bluffers Guide to the Mythical Man Month

#34

Post by NeoTar »

rco8786 wrote: post #32

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 project…

Is this not just a different manifestation of the third key observation?

"Division of Labor: There’s a limit to how effectively a task can be partitioned among multiple workers. Some tasks simply cannot be divided because of their sequential nature, and for those that can be divided, the division itself can introduce extra work, such as integration and testing of the different parts."

Just replace 'workers' with 'teams'.

Re: The Bluffers Guide to the Mythical Man Month

#35

Post by ponector »

lordnacho wrote: post #5
WJW wrote: post #4

Earlier quoted context omitted.

The article also points out that programming, even more than other professions, suffers from a lack of available "old people in the trenches" who can pass on these ideas to newcomers. This is because: - the field has been growing so much that at any point in time the majority of devs will be relatively new. A field that doubles every three years will never have more than 50% of people with more than 3 years of experi…

Yeah I also get this feeling that a lot of junior devs decide they don't really want to do it anymore. It's hard to get numbers on it because they will still have a related job title.

Yeah, for the whole my career in tech, except the first year I had such feeling. Don't want to do it but couldn't leave this golden cage of enterprise bulshit development.

Re: The Bluffers Guide to the Mythical Man Month

#36

Post by bigbillheck »

intelVISA wrote: post #13
misja111 wrote: post #3

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 a…

Despite many attempts to ignore this reality, entire languages like Go were invented to try mitigate this disparity.

Many things are invented to solve problems that don't actually exist.

Re: The Bluffers Guide to the Mythical Man Month

#37

Post by gjadi »

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.

Re: The Bluffers Guide to the Mythical Man Month

#38

Post by jSully24 »

pie314isi wrote: post #12

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

>”give him 2 copies so he can read it faster”

Gold! My week is made, no matter how many deadlines I blow past.

Re: The Bluffers Guide to the Mythical Man Month

#39

Post by civilized »

misja111 wrote: post #3

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 a…

Has anyone else started feeling the following? In the last year or so, reading a banal, superficial, and platitudinous summary of something has, for me, become inflected with this feeling that it was written by GPT.

In the case of this article, there are little details that suggest it was written by a person, like randomly choosing to abbreviate the book to T-MMM. But still, it's started happening for me that an article can feel "GPT-ish".

Re: The Bluffers Guide to the Mythical Man Month

#40

Post by lordnacho »

Almondsetat wrote: post #28
lordnacho wrote: post #14

Earlier quoted context omitted.

This is the thing. A degree is closed-ended. You build things that can be done within a deadline, and have been done within that deadline, by hundreds of groups before you. You study well known problems that are described in many ways in various sources. When you work, you work on building things that don't have a specific end goal, without a specific deadline, where the success criteria are also not purely academic.…

Then how do civil engineers get their degrees?

At university, like everyone else? Sit there, study structures, materials, etc. Get a job, get a charter...
Post reply on HN