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

71–80 of 95 posts

Re: The Bluffers Guide to the Mythical Man Month

#71

Post by nxobject »

taeric wrote: post #54
sizzzzlerz wrote: post #50

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.

I'm a bit of a broken record on the idea, but I'm fairly convinced that much of what we think is unique to software is not that unique. Coordinating work with people is hard, pretty much period.

I think we forget how much software engineering should be influenced by other engineering disciplines, rather than the other way around – I think there are plenty of cautionary tales of "move fast, break things" physical things startups.

Re: The Bluffers Guide to the Mythical Man Month

#72

Post by makapuf »

mrkeen wrote: post #21
intelVISA wrote: post #13

Earlier quoted context omitted.

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

This is starkly opposed to how Go is marketed, especially here on HN. Go was designed to maximise the number of 'any developers' that could join a project, i.e. 1x developers.

I get the assomption that with go you will avoid 0.2 programmers and make everyone a 1x programmer. But for me, a 10x programmer can generate complex, well engineered systems with a reasonable structure, not by writing everything in low level, super hard code ? From the level a 10x programmer might operate I'm not sure the programming language would be that important ? Expressivity is nice and some languages are better than others, but from my experience you can write nice artifacts from plain tools?

Re: The Bluffers Guide to the Mythical Man Month

#73

Post by loloquwowndueo »

dmbche wrote: post #62
paddy_m wrote: post #61

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

Classic "You get promoted until you are incompetent" situation

That’s another book: the Peter Principle, by Laurence J. Peter. It’s also in my “books you need to read if you’re going to work on a development team” list.

Re: The Bluffers Guide to the Mythical Man Month

#75

Post by burnished »

Almondsetat wrote: post #7
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…

I think the problem is that Computer Engineering is still not an engrained concept in universities. Sure, there are courses where some concepts are taught, but it's difficult if not impossible to tailor your degree towards being a real engineer.

Side note; I suspect you mean software enginee? Computer engineering is absolutely a degree and concerns the engineering of a computer. Starts off like an EE, ends up taking classes like 'microprocessor design' in place of power systems and the like.

Re: The Bluffers Guide to the Mythical Man Month

#76

Post by NegativeK »

danielovichdk wrote: post #70

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.

When I read it, I was saddened that most of the fundamental errors were still happening at my workplace decades after it was written.

Re: The Bluffers Guide to the Mythical Man Month

#77

Post by dmurray »

INGELRII wrote: post #19
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…

I agree. Mythical Man Month is a book to read. It's clear, interesting, and has better writing than summaries. Many classics like this are so good because the author is among the first to observe new phenomena. They can write down what they have learned without cultural narratives that distort reality. The hardest lesson in the book is the chapter 11 "Plan to Throw One Away". I have never seen this not to be the case…

> The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer.

It's not that clear! Perhaps you will only learn the lessons of why the throwaway version sucked by delivering it to customers. And it might buy you a lot of time, perhaps multiples of the initial time to get the pilot working.

Brooks has a point, but it may have been more true in the days of shrink-wrap software than SaaS and continuous updates.

I'd argue that it's more important to build an institution capable of retaining knowledge. The worst results are when the pilot system sucks and a whole new team is brought in to build the second version. They'll inevitably start building their pilot version, which sucks, and repeat until management gets sick of funding new teams for the same project (I feel this happens disproportionately in banking for some reason). Instead, you need to keep substantially the same team around to fix their mistakes in the second version.

Re: The Bluffers Guide to the Mythical Man Month

#80

Post by sebg »

loloquwowndueo wrote: post #73
dmbche wrote: post #62

Earlier quoted context omitted.

Classic "You get promoted until you are incompetent" situation

That’s another book: the Peter Principle, by Laurence J. Peter. It’s also in my “books you need to read if you’re going to work on a development team” list.

Intrigued to hear what else is on your list?
Post reply on HN