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

61–70 of 95 posts

Re: The Bluffers Guide to the Mythical Man Month

#61

Post by paddy_m »

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.

Re: The Bluffers Guide to the Mythical Man Month

#62

Post by dmbche »

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

Re: The Bluffers Guide to the Mythical Man Month

#63

Post by RandallBrown »

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.

Yup, this book is always in the must read list for software developers but I've barely met any product/project/program managers that have even heard of it. They're often the people that would gain the most insight from the topics in the book.

Re: The Bluffers Guide to the Mythical Man Month

#66

Post by strangattractor »

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…

And by 20K/yr programmer he likely means more experienced. Programmers tend to interpret this 10X as rockstar extremely prolific code programmer. In my experience the 10X programmer doesn't do things that impede the group or has enough experience to reduce the solution space to something manageable. Writing code is only part of the equation. Getting to a solution that works well cuts the time and lays the ground work for iterations and improvements. People the spew code that generally works are not as helpful.

Re: The Bluffers Guide to the Mythical Man Month

#67

Post by TheOtherHobbes »

lordnacho wrote: post #14
Almondsetat wrote: post #7

Earlier quoted context omitted.

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.

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

Thats not the only problem. In most engineering you build a mathematical model first, play with it until it's right, and only build the product when you're fairly sure it's going to work.

With a bridge, the model tells you about the forces in the structure, the component tolerances, and the likely behaviour under various stressful and extreme conditions.

Same with EE. Commercial board design uses schematic simulation, automated layout, and loading/transient emulation. You can't do modern commercial PC motherboard design without modelling software. (Well - you can. But it'll take far longer and be far less reliable.)

Software dev is more a case of nailing things together until they probably mostly sort-of work.

There's some guild lore - which changes fairly regularly - but no formal modelling. Realistically it's somewhat informed guesswork based on the current lore, mostly tested by trial and error.

Re: The Bluffers Guide to the Mythical Man Month

#68

Post by AdamH12113 »

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.

Re: The Bluffers Guide to the Mythical Man Month

#69

Post by zdragnar »

johnnyanmac wrote: post #48
INGELRII wrote: post #19

Earlier quoted context omitted.

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 hardest lesson in the book is the chapter 11 "Plan to Throw One Away" On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".

Part of the problem is you don't necessarily understand the problem domain very well when you're starting out. There are plenty of examples of microservice architecture failures due to incorrectly dividing services- either causing too much internal communication for performance acceptance criteria, or struggling with service coordination when performing changes that impact multiple relationships.

You may well end up throwing away some or many of your early microservices as you grow and the company better understands what it wants to build.

Or, you can take another approach (which i have witnessed first hand), throw it all away and go back to a regular, well designed monolith and getting very significant performance improvements by doing things like SQL joins and transactions instead of putting events in a message queue and paying network traffic penalties.

Re: The Bluffers Guide to the Mythical Man Month

#70

Post by danielovichdk »

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.

Post reply on HN