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

11–20 of 95 posts

Re: The Bluffers Guide to the Mythical Man Month

#11

Post by jwestbury »

WJW wrote: post #4
lordnacho wrote: post #2

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.

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 a big part of the "old people in the trenches" problem is that tech has historically had an "up or out" mentality. It seems like most of the older engineers I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. I've encountered a few people who have managed to avoid this, but it's rare.

It doesn't help that our industry has been incredibly fast-moving compared to most industries, and our interview process is geared toward either being a fresh grad who's taken and algos class recently or knowing all the latest frameworks. Not a lot of places are interviewing on the sorts of experience you gain over a couple of decades in the industry -- which, to be fair, is often more intangible and harder to interview on.

Re: The Bluffers Guide to the Mythical Man Month

#13

Post by intelVISA »

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.

Re: The Bluffers Guide to the Mythical Man Month

#14

Post by lordnacho »

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.

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. To the extent your problem is technical, you may be exploring the cave for a heck of a long time with no light.

You end up fighting with organizational issues as well.

Re: The Bluffers Guide to the Mythical Man Month

#15

Post by Aeolun »

jwestbury wrote: post #11
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 a big part of the "old people in the trenches" problem is that tech has historically had an "up or out" mentality. It seems like most of the older engineers I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. I've encountered a few people who have managed to avoid this, but it's rare. It doesn't help that our industry has been incredib…

> I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people.

It doesn’t really help that young people always feel like they know better either.

Even if there’s an experienced architect, it doesn’t help if they’re surrounded by 10 rookies. Nobody has the time to guide all of them.

Re: The Bluffers Guide to the Mythical Man Month

#17

Post by wavesbelow »

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.

I sympathize with your sentiment, but I don't think Go has anything to do with this.

The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1].

It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly.

Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way.

1. https://danluu.com/people-matter

Re: The Bluffers Guide to the Mythical Man Month

#19

Post by INGELRII »

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 in large systems. You must design the system to be rewritten. Accepting this is still a taboo.

> In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.2 Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.

>The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. 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. Delivering that throwaway to custom- ers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.

>Hence plan to throw one away; you will, anyhow.

Re: The Bluffers Guide to the Mythical Man Month

#20

Post by throwawaaarrgh »

lordnacho wrote: post #2

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.

I'd call them eventualities more than ideas. Do X thing in Y way and certain things are going to result every time. Somebody finally puts that in a book. But most people are either ignorant of it, forget it, or ignore it.

We can't just assume the people we hire will avoid the eventualities. This is why we need process, to force people into working in ways that avoid as many of the problems as possible. But then the problem becomes getting people to do the process correctly.

I believe the one thing that could transform the industry most significantly is better management. Most managers and team leads I have worked with, even if they've heard of these books, do not act in ways to prevent their problems. They fall into a rut, because they are not following a process.

It gets even worse when they claim to be following a process but aren't. There's loads of business improvement processes out there, but most are paid lip service. Then people get jaded at the process rather than the person or leadership team who clearly wasn't doing it.

Post reply on HN