"Mythical Man-Month" Supposedly Busted By MIT Startup 231
An anonymous reader writes "We all know about the Mythical Man-Month, the argument that adding more programmers to a software project just makes it later and later. A Linux startup out of MIT claims to have busted the myth, using an MIT holiday month to hire 20 college student interns to get all their work done and quadrupling its productivity."
!MMM (Score:5, Insightful)
In other words: they had an "embarrassingly parallel" problem and did the obviously right thing.
Re:!MMM (Score:4, Insightful)
"In other words: they had an "embarrassingly parallel" problem and did the obviously right thing."
Exaclty I'd like to see the poster try to keep adding people to a game project. I've seen so many abortions from the game industry lately it's disturbing.
Re: (Score:3, Insightful)
You could, to some degree, if you divide the work up correctly. You probably can't have more than a small number of people working on the game engine or deciding on the story line, but you can massively parallelize the people designing models, skins, etc., letting them pop items from the queue of object requests coming from the people writing the story li
Re: (Score:2, Insightful)
Not to mention that these are MIT students. #1 computer science program in the world. Not exactly a representative sample.
Re: (Score:2, Insightful)
You really can't count any such accolades until *after* they graduate. The day they enter they're nubs like every over CS student in the world.
Re:!MMM (Score:5, Insightful)
Even as a paying student, it's hard to get to MIT - so they're not nubs like every other CS student in the world. Or if they're nubs, they are the best nubs around (I'm not talking about average, but about the 20 or so people that could be attracted into such a project)
Re: (Score:3)
You really can't count any such accolades until *after* they graduate. The day they enter they're nubs like every over CS student in the world.
No, they're not. They're better than all/most other new CS graduates. That's the whole point...
Re:!MMM (Score:4, Insightful)
Computer Science != Software Development
They may be smart, they may even be brilliant, but computer science at elite institutions has frak-all to do with software development. At best, they will be good newbs, at worst, entitled newbs who are convinced they know it all.
Re:!MMM (Score:5, Insightful)
"Not exactly a representative sample."
And not a respresentative case till some time passes on. Right now they had a lot of youngsters hacking a lot of separated (micro)projects. Let's see in a few months if this hackaton doesn't become itself a maintenance nightmare, once bugs and design flaws arise.
Re:!MMM (Score:5, Interesting)
I wish I had mod points. This needs to be modded up.
I work for a large FW company and we host interns regularly. I am always surprised (shouldn't be) at what passes for projects assigned to them. I participated in a code review for one of these. Nothing prepared me for the abomination of code I encountered.
Now, 6 months past, I noticed another team deployed that code in their group and is coming back to our team to fix it since it originated from our group.
Smart ne Experience. This article was short on detail but long on dumping on Mr. Brooks. I think they need to (re)read his book.
Re:!MMM (Score:5, Funny)
So, 198% of game developers are morons?
Re: (Score:2)
No, double the nines. Four nines of game developers are morons instead of two nines of regular developers.
Re:!MMM (Score:5, Funny)
Vader: I am disappointed with your apparent lack of progress.
Imperial Deathstar Commander in charge of construction: But my men are already working 24hrs a day!
Vader: I want you to double your efforts!
Imperial Deathstar Commander in charge of construction: You want us to work 48hrs a day?
Vader: Listen, I'm a sadist not a mathematician!
(Mad Magazine's spoof on Return of the Jedi)
Niney McNine Nine (Score:3, Insightful)
Game devs FTW!
Re: (Score:2)
IMO, the distribution is rather:
30% college dropouts and recent finshes from questionable schools.
40% "stuck here 'til I find another job", average tenure 3 months.
30% good, dedicated and thus burned out
The rest is doing the work.
Re: (Score:3, Funny)
The rest are project managers who know shit about software and are on coke (the white, powdery kind)
Re:!MMM (Score:5, Funny)
So, 198% of game developers are morons?
Spoken like a game developer. Anyone with a clue knows that -37% of game developers are morons.
Re: (Score:2)
So, 198% of game developers are morons?
Spoken like a game developer. Anyone with a clue knows that -37% of game developers are morons.
How are you counting ? You must be a game developer.
198% (unsigned) = 11000110b% = -58% (signed)
Or -57% if you're developing for a platform using one's complement.
Agreed (Score:5, Insightful)
In addition, the article notes that the company was "a bit spoiled" by being in a position to hire from a large pool of MIT students, many of whom they knew personally. I like the subtle understatement here.
Not only did they put the target practically in front of the gun (by having an embarrassingly parallel problem), they also employed an embarrassingly high-calibre gun (i.e. hand-picked MIT students). Scoring has therefore been high. Surprise!
This experiment didn't do anything at all to bust the mythical man-month. Who came up with that title anyway? Must have been some slashdot editor ...
Re:Agreed (Score:5, Informative)
And they deliberately attacked the problem noted in TMMM - that of communication and ramp-up - by seating everyone in the same room(s). And yes, working on independent problems. And those problems were not already late, in that the schedule had not yet started (TMMM is about adding people to an existing, complex project that is already running and having the communications, ramp-up, skills transfer and other sundry distractions causing an increase in work required that is greater than the increase in available effort).
Stupid, wrong, inflammatory and deliberately misleading headline, and summary, perfect for /. ! Go editors go!
Re:Agreed (Score:4, Insightful)
TMMM is about people actually having to communicate. The situation described here put everybody in the same room due to there not being enough rooms. Given the task, they might as well all had separate office buildings.
I've worked on in companies with well over thousand IT employees. Those companies didn't have a problem with TMMM either. That's because those thousand people were working on a hundred different projects. This situation is pretty much the same but at a far smaller scale.
p.s. When an article mentions the product they are making is "supposed to be technically impossible", the rest of the article probably isn't based on reality either.
This has nothing to do with TMMM, but with them bragging about how they hired a shitload of MIT students and assign each his/her own, separate projects; something any half-decent project manager should be able to pull off. (And this is a guy speaking with a very low esteem of project managers in general).
Re: (Score:2)
In the real world people get hired are hand picked and are usually people the boss or someone on their teams know.
Its a real problem when you are fresh out of school and no one has ever heard of you. Networking is an important part of a job. This is especially true the more higher up you are on the corporate ladder. CEO's are hired on the basis of having extensive contacts with vendors and other companies to increase sales.
Re: (Score:2, Insightful)
To be fair, there was a risk of run away egos torpedoing the project.
Embarrassing parallelism (Score:2)
In other words: they had an "embarrassingly parallel" problem and did the obviously right thing.
Yes, they split the problem up into numerous tiny atomic work units to be handled simultaneously by 20 threads, and then had each intern write one.
Re:!MMM (Score:5, Insightful)
Exactly. They didn't add people to a late project, they got more people and put them on un-manned projects to get them going. That's quite a different matter and not what Brooks was talking about. And yes, they did the right thing.
Re: (Score:2)
More likely the submitter read the damn article which references the Mythical Man Month, and has never heard of Brooks let alone read the book.
Re:!MMM (Score:5, Insightful)
Even there, they didn't come anywhere close to disproving Brooks' theory.
If you throw 20 programmers at a task, the square root of 20 is 4.472+. They got a factor of 4 (at best) improvement. To even begin to claim that productivity improves with the number of programmers (modulo a constant), they'd need to beat that square root.
They failed. The numbers they're quoting are certainly inconclusive, but in a vacuum they support a sub-linear improvement (the Brooks hypothesis), they don't refute it.
Certainly there could be a very small constant where these results are inline with a non-Brooksian conclusion, but in a vacuum they're more likely in line with a Brooksian hypothesis than any theory of linear scaling.
Re: (Score:2)
EDIT: the more I read the article, the angrier I get.
It's really pretty close to claiming that one limited test shows that Python or Tcl or Ruby or C# or Perl or Java or ColdFusion or whatever (call it language X) is only 20% slower than C, therefore people who claim language X is slower than C are idiots.
The purported "evidence" against it is actually supporting the Mythical Man Months' theory.
Re: (Score:2)
Re:!MMM (Score:4, Informative)
Actually, the Slashdot Effect [wikipedia.org] is generally recognised to be basically DDoSing a server because too many people are trying to access it at once. But yes, there is a lot of sensationalism and groupthink here.
Totally misses the point (Score:5, Informative)
If you RTFA, they don't really address Brook's point. They all worked on small projects. Where the mythical man-month applies is in the combined effort on a large, sufficiently complex project. The real breakdown comes in the collaboration and communication.
Besides, in the real engineering world, nobody is going to tolerate the work conditions they describe. The pay better be 10x what I earn now to pack me in a room with sweaty, overweight 40-somethings.
It's a cute college experiment and nothing more.
Re:Totally misses the point (Score:5, Funny)
They all worked on small projects. Where the mythical man-month applies is in the combined effort on a large, sufficiently complex project.
You're just quibbling about details. If they can get 40 interns to do 40 small problems quickly, they can certainly get 40 interns to do 10 large problems even faster. Just like 9 pregnant women can make a baby in one month. Or they can keep the original 9 month schedule, but pool their efforts to create one super-huge baby.
Re:Totally misses the point (Score:5, Funny)
And that, folks, is what happens when you cross the streams. Never cross the streams!
Re: (Score:2)
Right. That's bad. Okay. All right. Important safety tip. Thanks, Egon.
Re: (Score:2)
It's a small world. (Score:2)
You replace it with something else. I recommend singing "It's a small world..."
Re: (Score:2)
Re: (Score:2)
Oh, sure, that's an apt analogy, because as we all know, the problem with 9 chicks trying to make a baby in one month is exactly that: crazy communication.
Re:Totally misses the point (Score:4, Informative)
If you RTFA, they don't really address Brook's point. They all worked on small projects. Where the mythical man-month applies is in the combined effort on a large, sufficiently complex project. The real breakdown comes in the collaboration and communication.
They addressed Brooks' point by having lots of small projects instead of one big ball of spaghetti code.
Here's a quote from the 20th anniversary edition ("The Mythical Man-Month after 20 years" chapter):
The underlying reason that man-months are mythical is because of communication overhead; if everyone has to know what everyone else is working on, your team can not scale. In the section I quoted Brooks goes on to talk about easier reuse and fewer errors, but proper encapsulation also has the effect of dramatically reducing the overhead of extra people -- now instead of operating on the system as a whole, the law operates on individual subsystems or modules.
In this case Brooks' Law was addressed by whatever design or happenstance led to (1) the projects being independent instead of intertwingled, and (2) there being enough of these independent projects for all the interns.
Re:Totally misses the point (Score:4, Informative)
Which is just like scaling a database. Adding slave servers will only get you so far, as each slave still has to read through all the data. Only by sharding can you expand beyond a certain point.
Relating to Open Source? (Score:4, Insightful)
Let me see if I get this right:
Brooks is saying that you should let everybody look at source code, due do Linus' Law (bug shallowness goes to 100% for eyeballs going to 6e9).
Parnas is saying that you should encapsulate things behind loosely coupled interfaces.
And you're saying "if everyone has to know what everyone else is working on [...]"
And then I'm saying there's a difference between having to know the innards of a module, and being allowed to know said innards.
I also think being allowed to know---without having to---is what makes open source software what it is.
Re: (Score:2)
Agreed. From TFA:
"had a growing queue of important engineering projects outside of our core technology"
outside the core technology is the important part
The MM-M is more what you'd call a guideline (Score:5, Insightful)
than an actual rule.
Re:The MM-M is more what you'd call a guideline (Score:5, Insightful)
Someone hand that guy a modpoint or two, because adding manpower to a late project can have beneficial effects. If, and only if, it is done sensibly.
Hire someone who makes sure the programmers have all the pizza and egg rolls they need so they ain't going to be distracted by having to call the pizza place for one. You all know how much time is killed with you get interrupted by something important. Like, say, a rumbling stomach. It takes ages to get back into the code afterwards.
But more sensibly, fire all the paper pushers and hire project managers worth their salt. And I don't mean "idiots that can set arbitrary milestones". We got plenty of those. A good project manager makes or breaks the project. What I need from a project manager is:
1) Making sure I have the hardware and software I need. Not "the company thinks I need". The ones I need.
2) Making sure external sources keep their deadlines or route around those bottlenecks. Know what makes most of my software late? That I finish my modules only to hear "uh... testing can't commence, we're waiting on something from X." A good PM knows that BEFORE it happens and tells you to drop that module and work on this one instead, because the guys at Y are done and we could start testing that part instead.
3) Most important: SHIELD ME FROM POINTLESS MEETINGS and go there for me. And there, his answers are "no". "Can't do that". And "has to be done on your end". I.e. the crap I usually get to hear in those meetings.
If necessary, hire more PMs. Not more programmers.
Can it really be true? (Score:4, Funny)
You mean hiring awesome staff to work on independent projects designed in advance breaks Brooks Law?
Genius! Pat yourself on the back some more. /sarcasm
MIT holiday month (Score:3, Informative)
Re: (Score:2)
Or drinking copious amounts of booze while it's too frackin cold to go outside anyway.
Re: (Score:2, Funny)
I'm a beaver, you're a beaver, we are beavers all And when we get together we do the beaver call
E to the U, dU dX, E to the X, dX
Cosine! Secant! Tangent! Sine!
3-point-1-4-1-5-9!
Integral! Radical! mu, DV
Slipstick! Slide rule! M.I.T.!"
They didn't add to a late project (Score:4, Insightful)
They didn't add programmers to a late project, they added programmers to a bunch of small, self-contained projects that hadn't been started yet. That's a very different thing.
The point of Fred Brook's argument is that if you take a project that's already late, that means it already has systemic problems of one type or another (or likely, several types at once). Adding bodies without solving the systemic problems just makes those problems grow, not go away. That's not the situation this company had and that's not what they did. Saying they "busted the mythical man-month" is just trolling.
Re: (Score:2)
Nope (Score:5, Interesting)
No they didn't. The communication cost remained O(n^2), they just improved the constant multiplier, not the order. To actually bust the MM theory, they should have quadrupled a couple times more, and see whether the productivity going down the drain or is as scalable as they claim.
Re: (Score:2)
Actually, they directly attacked "N". If you poured 40 people onto one project such that they all had to coordinate, you'd have 40*39/2 = 780 cross connections. (This is where the O(N^2) comes from.) Instead, they poured 40 people onto 40 more-or-less separate projects. That's more like 40 instances of an N of 1.
Re: (Score:2)
No they didn't. The communication cost remained O(n^2), they just improved the constant multiplier, not the order. To actually bust the MM theory, they should have quadrupled a couple times more, and see whether the productivity going down the drain or is as scalable as they claim.
Indeed. Brooks noticed the problems on a team with (AIUI) over 1,000 programmers. If this company can scale up an order of magnitude or so and still keep their performance-per-programmer high, I'd love to know how they manage it.
In other news (Score:2)
College kids claim to know it all.
Yes, it may be MIT. However let's see what happens AFTER you graduate...
Doesn't negate Brook's adage at all (Score:2, Insightful)
Put these same kids on an existing program that is a year late and already has a team of 20 programmers working on it. Get back to me in 6 months telling me just how fine things are.
Re: (Score:3, Insightful)
In that case, I suspect firing the right 5-7 people (some of them programmers, but not all of them) would get the job done faster.
Re: (Score:2)
The Mythical Commenter-Post (Score:4, Funny)
Re: (Score:2)
the argument that adding more commenters to a thread just makes the posts dumber and dumber.
That's a MYTH??
Re: (Score:2)
Where am I? Digg? (Score:5, Funny)
Re: (Score:3, Funny)
10 years ago (Score:5, Insightful)
The real issue here, and one that is not addressed, is the quality of code. What the MMM addressed, IMHO, was adding developers to a project with defined metrics and ending up with code that met those metrics and integrated well with a larger code base. The reason that adding people did not work was the overhead needed to communicate between the develpers, which is 2^n proposition
As such, until the code is proven in service one cannot really say if the experiment worked. If the code is just going to have to be re-factored, or interfaces rewritten, then nothing was done other spending money to achieve a minimal product to meet a deadline. This is important, but does not prove or disprove anything.
Re: (Score:2)
Re: (Score:2)
If the developer is schizophrenic, then it might be n^2, otherwise it's probably (n(n-1))/2.
This is MIT, remember (Score:5, Interesting)
The thing is, though, Google gets away with this because they hire the best of the best, and the best of the best can manage themselves pretty well. Most programmers are nowhere near as talented as the ones working at Google, they're the ones who need to be supervised. Managers are for programmers who write code that ends up on The Daily WTF, which is many of them.
I suspect that's what's going on here. Of course a bunch of MIT students can just hop on a project and be productive, that's why they're going to MIT. This result does not apply to the world at large.
Having said that though, I bet some of the techniques they used would apply to the world at large. I for one am going to see what I can learn from this with regards to getting people up-to-speed on new projects.
Re: (Score:2, Insightful)
Re:This is MIT, remember (Score:5, Insightful)
No. No! I need a project manager! And I pride myself with being a fairly good programmer. And even the guys at MIT can benefit from one.
But I, like every programmer, need a good project manager. One that helps me instead of standing in my way. I don't need someone who checks my "progress" on some arbitrary measure that has nothing in common with the project at hand and peppers my calender with meaningless milestones. I also don't need someone to tell me how to write my code. I need a project manager that understands what he and I are trying to do together: Make a project work out. My job is to create it. His job is to make that possible to me.
And for that I need a project manager that deals with what I tend to call the "unpleasantries" of projects. In other words, clients, management, in a nutshell: PEOPLE. People make a project late. Especially when they start to meddle with it for some reason. The perfect project manager would lay down the project together with the client, do all the yucky legal stuff around it, give me the specs (not "and here kinda-sorta like $other_program", I mean specs you can work with), then keeps customer, management and all the other unnecessary evils of a project busy while I do my job so I don't get pestered. By meetings. And dumb questions.
I once actually had a PM like that. And it was a dream. We (him, me and a few other very motivated and talented people) created projects in record time. It was the best year of my life!
The company did what it does in such cases: They promoted him away from the position he was born for.
Re: (Score:3, Insightful)
It sounds like in every case where there is a good program manager who's helping you do your job, there's utterly incompetent management above him. What actual good does the higher level management even do, if you need a person just to shield you from them? How are they not a net drain on the company? Do you think the program manager could in theory run everything without the company suffering?
Re: (Score:2)
9 women and the baby (Score:4, Funny)
Tiger Woods (Score:4, Funny)
Is this the same rule as "9 women can't make a baby in 1 month"? I tried to explain the rule to our HR lady and it didn't go over really well with her.
I thought Tiger Woods was trying to prove that rule wrong.
Re:9 women and the baby (Score:4, Funny)
"9 women can't make a baby in 1 month"
Ah, yes, 1 baby per month is what you would expect for the classical case, but if we model the baby as a particle in a time box we actually expect 2/9*sin^2(n*pi*t/9) babies.
Some people just don't stop to think about the realism of their model!
Re: (Score:3, Insightful)
But seriously and aside of sexism and stereotypes: I had my share of companies to work with, from employee to consultant, and without fail the HR head was female and by any standard a true, absolute and impossible to stomach bitch. Please note that I have nothing against neither woman nor people who find pleasure in working in HR (they do a job I wouldn't want to touch with a ten foot pole. Both of them, actually...). But why is is that the HR bitch is by default the dragon of the company everyone would sla
The ORIGINAL development project (Score:2)
On The Other Hand (Score:2)
I once worked for a company that hired a few extras to appear as if they were hard at work on computers in order to land a large contract. We only had them set up to look like they were working for one day.
Re: (Score:2)
Hmm... that explains why in a company I worked for an (unemployed) dancer was working as a temp... allegedly he did interface design, but after reading your comment, I'm not so sure anymore that this is the entire story...
Disappointing (Score:5, Interesting)
I have been a slashdot reader since darn near the beginning (see uid). And I finally have to admit that the quality of information here has seriously gone downhill. As everyone else has rightly pointed out, the article is bogus. They didn't break Brooke's law.
Just yesterday a server I administer which runs a very non-optimized PHP and graphics and database heavy site was linked in a story on the front page. The server barely noticed the load. A hit every other second or so. And it was a direct link, no coral caching or whatever. I remember a day when slashdot had enough readers to utterly destroy a single server. It looks like a lot of people have taken off. If this continues I may have to take off too. As it is reddit, hackernews, and many other tech news sites with superior content in my rss feed are competing with slashdot for my eyeballs. I may finally have to trim slashdot from the list if this keeps up.
Re: (Score:2, Insightful)
Re: (Score:2)
Re:Disappointing (Score:5, Insightful)
Not as old as you (in terms of Slashdot readership), but I've been here quite some time as well.
I think that, as readers left this site, editors slashed into the content quality and try the quantity approach. I used to be able to read the site daily and have time to post replies here and there. Now, I have it set in an RSS reader because the volume is much larger to the point that if I miss a day, 20 to 30 stories fly by.
It's not that there are more things to report now than 10 years ago, it's all these crappy filler stories, blog posts about nothing interesting, jokes and whatnot that make this site less and less relevant.
Additionally, while Slashdot used to be where the breaking news was happening, I can now find interesting and important stories up to THREE days later on this site than on digg, for example.
Me and some other people have submitted, days ago, important stories (in our opinion) about a FOSS company that is suing the Quebec government for the right to bid on contracts that went directly to Microsoft. This is being heard by the supreme court right now. The supreme court! And it's not even making slashdot!
It's not too late, but the editors really have to try and voluntarily lose a few percent point of page views in order to bring back quality and, more importantly, fellowship of readers.
Re:Disappointing (Score:5, Insightful)
If you think stories shows up on Digg before /., you should check out Reddit (especially the various tech subreddits). That's where you find the stories 4 days before they show up on Digg.
Nowadays, I mostly come to /. for the discussions. I will admit that the quality of discourse might have sagged a bit since its heyday, but on a whole I still find genuinely stimulating articles and commentary often enough to be a regular reader after all these years.
Re: (Score:2)
Can I have your ID?
Ok, ok, seriously. Well, times change, so does the IT audience. Turn back the wheel by, like, ten years. Peak of the dot.com bubble. The news were different, the audience was different, many of the people reading here today weren't even part of the workforce back then (you pretty much have to be near your 30th birthday if you are). Without wanting to invoke "get off my lawn" replies, I think this might be the reason.
Unlike "older" people, like me and probably you, these people grew up wit
Re: (Score:2, Funny)
Re: (Score:2)
Dude, just jump ship already. I just read Slashdot these days for the perverse pleasure of silly stories. :-)
P.S. This article hit front page YC and Proggit several hours before Slashdot.
Re: (Score:2)
Don't forget (Score:4, Insightful)
The key to limiting, or exasperating this problem is good or bad project management.
Of course, if the 'project' is a large series of little projects that don't have dependency on each other, you can greatly increase personnel easily, such as the people in this argument.
They didn't really bust the myth, rather they used a situation where they didn't exceed the number of optimal personnel.
Diminishing rate of return (Score:2)
You should be able to increase productivity the more people you add. However, the return gets smaller and smaller [wikipedia.org] as you add more people.
Think of a McDonalds. If you walk into one with only 2 people working you would end up with slow crappy service. Three would be ALOT better as one can man you, the cash registers, and the drive thru. Four workers would be a nice increase, five would be ok I guess, 6 would not bring "your burger much faster, by the time 7 and 8 go in you would not see much improvement, etc.
Re:Diminishing rate of return (Score:4, Interesting)
There are two things here. Several things can happen in term of 'scheduling theory'
-you can have 'super linear speed up' : put 2 workers and go 4 times faster. Think about building an ikea furniture that REQUIRES 2 people alone. Or about specialized workers : it might be better to add a microwave to a kitchen than a second oven. In computer systems, cache/memory can lead to super linear speed or dedicated hardware acceleration like graphic cards.
-you can have 'linear speed up' : put 2 workers and go 2 times faster. This is usally the case when the problem can be divided in a lot of independent task like painting 20000 doors. In computer systems this happens when uncompressing videos for instance.
-you can have 'sublinear speed up' : put 2 workers and go 1.3 times faster. This happens when you need to do extra work to allow some several workers to work at the same time. As in tagging files so that other people can handle them (In computer science, computing a prefix sum array in parallel follows this principle). It also happens when there is not enough work for everybody (the 9 pregnant women case)
-you can also have 'negative speed up' : put 2 workers and go 1.3 times slower. This happens when people get in each others way fighting for the brush to paint. In computer systems, this is often the case when adding processors increase communication too much.
basic fail. (Score:2)
a million monkeys on a million type writers WILL NOT produce shakespear
Re: (Score:2, Interesting)
A million monkey's is nothing for this problem. If you had 1E100 monkey/typewriter pairs (>> atoms in universe), banging out random text at 200 WPM would will still never see a single copy of Comedy of Errors (his shortest play, 16,263 words) even if you waited 1E100 years -- You really need an infinite number of monkey/typewrites pairs, in which case you will have a Complete copy of ALL or his plays, translated into every language (representable by the typewriter character set) in under 3 hours (200
I see... (Score:2)
I own the book, but I have not read it.
I am off to found an MIT startup.
The old adage goes... (Score:2)
I guess the updated version of that would be: never hire anyone that went to a university that advertises on blogs.
1 office (Score:2)
Mythical Man Month (Score:2)
Actually it depends on the situation, but normally just dumping more people onto a problem does not work, they need time to get comfortable with the code, the structures the entire project, etc.. add to that if you cannot divide the problem properly more than 7 people working on a single problem start to begin to conflict each other. I have seen parts of a project getting a standstill when the magical 7 people number was reached due to conflicts etc... even if all of those were knowledgeable about the inter
Is this battery software farming? (Score:2)
So easy... (Score:2)
Sigh...
Maybe the biggest mistake in the man-month is to believe than any (wo)man can replace any other hence, the cheapest the better. That's the point I see busted.
Re: (Score:2)
you can not be a manager since you did something useful! :)
Re: (Score:2)
Get two such teams together. Then add them together to work on a single large project. See if productivity increased by a factor of 2.
Re: (Score:3, Insightful)
"Ok, geniuses. You've figured out how you should be running your company. If companies would just do these things, they would never find themselves in a position where they would be late in the first place."
I'm sorry but this is nonsense, in the real world all sorts of unexpected things happen or subtle flaws or errors you didn't know about can crop up that push projects back. Especially in the game industry - the preach iterative software development, if you're always iterating, you're constantly adding