11 ms·
The Bluffers Guide to the Mythical Man Month
- lordnacho 3y agoIt'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.
- WJW 3y agoThe 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 experience, obviously. - I have no numbers to back this up, but intuitively it feels like more devs "drop out" of software development than in other professions. Many become managers, others take up various non-development projects or retire altogether. This makes it so that even less senior people are available.
- lordnacho 3y agoYeah 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.
- poulsbohemian 3y agoAlmost 30 years ago I was a freshman cs student and a prof rolled out data that said by the time we were 30 years old, most if us would have already left the field. I can tell you that almost no one I graduated with is still working in tech, and not because we retired early off stock. It’s a challenging field for so many reasons.
- WJW 3y agoIt would be interesting to see how that compares with other professions. Do carpenters or dentists leave for other fields at the same rate? How about other types of engineers?
- polygotdomain 3y agoI can only speak of my experience having gone to school for Architecture. They told us that with each recession, the profession loses a generation of Architects. I was wrapping up grad school just before the Great Recession, and professors were surprised that a relatively greater percentage of graduates had stayed in the field due to continued economic prosperity since the mid 90s and the dot com boom hadn't impacted the Architecture field all that much. Of course, once the Great Recession hit, myself and many others that I graduated with either left the profession for other employment or simply never found jobs to begin with (that was me). Luckily I was already programming in grad school, and what was something I was filling my time with while looking for an architecture job became a new profession and I never looked back. Given all the comparative benefits of Software Engineering over Architecture, it's been a good move for me.
- hotpotamus 3y agoBased on my own experience, I don't find it hard to believe that so many want out, but I do find it hard to believe that so many get out and so quickly. These days I find myself wishing I had gone the route of physician's assistant so I could do some tangible, socially-needed work that still pays the bills. I've actually ended up in a tech job that hits those a bit, so I am doing a bit better these days at least.
- ponector 3y agoYeah, 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.
- Almondsetat 3y agoI 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.
- lordnacho 3y agoThis 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.
- Almondsetat 3y agoThen how do civil engineers get their degrees?
- lordnacho 3y agoAt university, like everyone else? Sit there, study structures, materials, etc. Get a job, get a charter...
- Almondsetat 3y agoSo why can't we have a computer engineering degree as you say?
- lfowles 3y agoComputer engineering degrees already exist, but they're much closer to the hardware.
- 3y ago
- jwestbury 3y agoI 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.
- Aeolun 3y ago> 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.
- deleted 3y ago[deleted]
- karmakaze 3y agoIn my experience rookies/interns/jr devs are a pleasure to work with: knowledge sponges. It's a small subset of ones becoming sr devs that can be difficult.
- throwawaaarrgh 3y agoI'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.
- dredmorbius 3y agoSince you bring up Smith, one of the absolutely glaring oversights of Wealth of Nations is that it utterly fails to grasp or note the role steam power would play in the next century of increasing automation, factory-system development, and transportation within England and the economies of Europe and North America especially. This is all the more gobstopping an oversight when you realise that Smith not only know of James Watt and his steam engine, but was personally acquainted with Watt, personally arranged for him to have a position at the University of Glasgow, and that that was specifically to work and improve the University's own steam engine. Watt remained at that post for a decade or more if memory serves, much of that prior to the publication of Wealth in 1776.
- misja111 3y agoThis 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.
- intelVISA 3y agoDespite many attempts to ignore this reality, entire languages like Go were invented to try mitigate this disparity.
- wavesbelow 3y agoI 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 https://danluu.com/people-matter
- mrkeen 3y agoThis 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.
- aaron695 3y ago[dead]
- bernardlunn 3y agoI read it in the 1970s as a youngster, now retired, brilliant then and now.
- pie314isi 3y agoonce, 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"
- danwee 3y agoI'm not sure if reading the book would help. If the manager has a technical background (e.g., they have worked as developers before) then they already know the main point of the book. If the manager does not have a tech background, then there's little that the book can do for them.
- mindsuck 3y agoYou believe every tech oriented person already knows everything there is in the book?
- Cthulhu_ 3y agoNo, 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.
- cptaj 3y agoEveryone experiences things daily without fully appreciating the patterns and insights that could be derived from it (would be exhausting if we did) The book most definitely helps tech workers.
- verbify 3y agoMany 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).
- jcmeyrignac 3y agoThis 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 https://gallica.bnf.fr/ark:/12148/bpt6k54409695.image.f14 A group of 8 persons provides the same amount of work as 4 individuals.
- rramadass 3y agoYep, This is why small teams work best. It also helps in maintaining better overall "Conceptual Integrity". Ringelmann effect - https://en.wikipedia.org/wiki/Ringelmann_effect https://en.wikipedia.org/wiki/Ringelmann_effect Social loafing - https://en.wikipedia.org/wiki/Social_loafing https://en.wikipedia.org/wiki/Social_loafing
- draw_down 3y ago[dead]
- rco8786 3y agoI'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.
- NeoTar 3y agoIs 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'.
- psychlops 3y agoPretty sure it simply represents the upper bound of communication complexity. Any management of it can improve coordination. The conceptual lower bound is that each additional programmer adds 100% more programming speed.
- ewst 3y ago> 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?
- supernewton 3y agoLaypeople use "exponential" to mean "superlinear". It's fine, probably.
- not2b 3y agoBrooks wrote that it was quadratic, so that seems to be an error in the summary.
- dragonwriter 3y agoLaypeople use “exponential” to mean “fast”, with what “fast" means varying by speaker and context.
- gjadi 3y agoAnother 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.
- sizzzzlerz 3y agoWhile 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.
- taeric 3y agoI'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.
- nxobject 3y agoI 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.
- dredmorbius 3y agoSystems in general have similarities. Human organisations, whether governmental, commercial, educational, religious, military, charitable, social, or any other principle focus, tend to have and exhibit strongly similar patterns. There is of course also domain-specific knowledge, but even much of that almost always proves more general on closer examination, with much of the distinction being of labeling and language rather than behaviour and phenomena.
- kwertyoowiyop 3y agoEvery engineer would benefit from it too.
- RandallBrown 3y agoYup, 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.
- fassssst 3y agoThe book only takes like an hour to read you know.
- drewcoo 3y agoWhen you try to read and discuss as a group, it takes much longer.
- maximus-decimus 3y agoYou can read 336 pages in an hour?
- fassssst 3y agoThe pages are very sparse and there’s lots of obsolete sections you can skip. The meat of it is in like two chapters.
- paddy_m 3y agoI 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.
- dmbche 3y agoClassic "You get promoted until you are incompetent" situation
- loloquwowndueo 3y agoThat’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.
- sebg 3y agoIntrigued to hear what else is on your list?
- loloquwowndueo 3y agoMy go-tos are the mythical man month and Peopleware:productive projects and teams. There’s the Peter principle too. On more technical (slightly) topics, I like the Pragmatic Programmer. I also like people to be aware of re-engineering concepts, so Hammer and Champy’s Re-engineering the Corporation is also good.
- tmcdos 3y ago
- AdamH12113 3y agoThe 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.
- danielovichdk 3y agoThe 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.
- NegativeK 3y agoWhen I read it, I was saddened that most of the fundamental errors were still happening at my workplace decades after it was written.
- monoscient 3y agoI'm so sorry but I read it as "the Mythical Moth Man" for a second
- smcin 3y agovery Kafka. If only the industry had adopted your 'vision'... Also, very Norm MacDonald (RIP).