182. Lessons From "The Mythical Man-Month" | THUNK
Vložit
- čas přidán 18. 02. 2020
- You wouldn't expect a 45-year-old book on programming to be relevant today, but Fred Brooks's "The Mythical Man-Month" contains many lessons about project management & design that should resonate with modern coders, problem-solvers, & creators.
- Links for the Curious-
"The Mythical Man-Month - Essays on Software Engineering" on Amazon - smile.amazon.com/Mythical-Man...
"The Mythical Man-Month" (exerpt) by Fred Brooks - www.cs.drexel.edu/~yfcai/CS45...
"Aristocracy, Democracy, & System Design" (exerpt) by Fred Brooks - docshare02.docshare.tips/files...
A high-level summary of TMMM - www.cs.usfca.edu/~parrt/cours...
InfoWorld Magazine, 1984-05-07 Issue - books.google.com/books?id=ti4...
I have seen this out in the wild so many times. I see it most often when a company gets contractor supplimental devs just for a big push and the core team ends up spending more time getting them up to speed then they would have just doing the tasks. I heard "ManMonth" in a meeting and had to know. I'm glad I found this video. Subbed.
As the saying goes "What one programmer can do in one month, two programmers can do in two months".
Valid.
Ok . Uinbn ko k I'm nnnm kl m kk kkl ll m
I think the most common manifest of the mythical man-month is with "staffing up" existing teams that work on projects that are already up and running.
You have to give the new people a tour of the codebase. Get the logins to all the required tools. Teach them your style guide for all used programming languages. And then give them the specific domain knowledge to get an idea of what all that code is doing in practical / business terms. Not only will that mean that the new people don't make meaningful contributions from anywhere between a week and a couple months - no, during that time other team members will be less productive, because they have to do all that on-boarding work, answer questions and do more extensive and lengthy code reviews.
I'm pretty sure that this works out in other professions as well. If you got a new engineer for your aeronautics company, you might have to spend some time with them to make sure they're working on the same level and triple-check their work where you only double-check that of long term members.
This also gets worse, when management treats staff as a dynamic resources they can scale up and down easily as requirements / demand goes up and down. Meaning you have to do all the above work every 6 months or so, without ever really reaping the benefits of the additional staff.
I've learned more from this channel than I did acquiring a degree in project management... Great video!
Whooooa! High praise! :D Thanks!
I agree.
Implementation is usually not the problem, those jobs that can be programmed (meaning of those problems which there exist some graph of computational code which maps required inputs to outputs) can be "automated" (which implies the process can be addressed as a black box over some level of confidence that the desires program behavior is sound).
A human at this point is our, "oh we don't have a program for that so let's use a human" metaprogram.
Sure, a human is more effective than any meta programming application we have today.
The real problem is in defining some predicate for what the input and what the final output should be. This is where most problems arise based on the vagueness of requirements definition, the experience level of our meta-programmers (human or machine), and the level of resource constraint of a development team has (what platform we are running our application on). Defining program specifications for inputs and outputs requires an understanding of the problem domain which pushes us back to dealing with problems as philosophies (what does it mean to show x data in this format).
You hit the point directly on this video.
There's a reason Brooks spends whole chapters talking about problem definition & building functionality based on test conditions! :P If you can get your client to commit to a test as the standard of functionality, you're golden.
no such thing as invesx, or x takex tx etc, think, do any nmw and any s k
It works (or rather, doesn't) the other way around as well: decreasing the project scope doesn't always speed things up, just as increasing the workforce doesn't always speed things up.
A clear way to demonstrate this is to take a peek at Amazon's Mechanical Turk service: continually reducing the size of a task until one person can accomplish 100 of that task in an hour doesn't actually speed up the task . . . it just circumvents minimum wage laws.
Great example of scalability not being universal, albeit depressing. :-/
Nice work. I think your channel will be huge soon.
"The more chefs the worse soup"
the video summed up in one line
🎵 Too ma-ny cooks... 🎵
Want to think better? Then listen up....here.
I wonder if things that can be man-monthed ear also tasks that could be easier done via automation. Which paradoxically cannot be made by man month systems....
Not always... take transportation as an example. It's a typical man-month-able job. Yet it is profoundly difficult to automate.
There are certainly correlates with complexity of the task at hand - brute force tasks tend not to require a lot of synchronization.
what about open source?
I think many successful open-source projects have a unity of vision & clarity of purpose, often driven by dedicated individuals. For example: lkml.org/lkml/2012/12/23/75
I can't make a baby in a month with nine women, but I'll sure as hell give it a go
Dooooooogggggg
*woof*
I'm a troll, stop responding to my comments.