The Mythical Man-Month Revisited 317
jpkunst writes "Ed Willis, over at O'Reilly's ONLamp.com, gives his varied reactions to Fred Brooks' classic The Mythical Man-Month, after 'having finally read it in its entirety'. '[...] simultaneously you can see just how much the field has changed since the original writing and just how much has stayed stubbornly the same.'"
The more things change ... (Score:5, Informative)
Another concept he brought to light was originally Harlan Mills's, that of making the programming team like a surgical team. A surgeon, or chief programmer, has primary architectural, design, and implementation responsibility, but is assisted by a copilot, administrator, editor, two secretaries, and a program clerk.
While I've never seen such a team, I have witnessed pair programming that the XP (not Windows, eXtreme Programming) folks praise, and it works quite well. It may not be a full-fledged surgical team as Brooks would've liked, but the productivity of a pilot on the keyboard and a copilot following after every little mistake certainly improves productivity.
Re:Am I the only one... (Score:1, Informative)
I'm from England. I love that book and it was taught to us as a college set text. so it's not an Americvan thing
Typo... (Score:1, Informative)
Re:Am I the only one... (Score:5, Informative)
If you were for example painting a big house or something it my take one man two months to complete. But if you had two men then it takes one month. The more people you add the faster the job it done. So we often talk about how many man months are needed to complete a job. But that are many tasks that cannot be made faster by adding more people. Brooks states that programming is one of those tasks. Adding too many people to the programming effort will only make it take longer because of interdependencies, communication and coordination required. The programmer and time are not fungible. We cannot simple expect to complete a project that takes 1 man 18 months with 18 men in 1 month. As you add more men the time improvements become less and less.
Re:Am I the only one... (Score:5, Informative)
Re:Still one of the best "I-was-there" books (Score:4, Informative)
It's called the "second-system effect".
Re:A Classic Book (Score:3, Informative)
Re:The more things change ... (Score:3, Informative)
But then, you could simply have read my comment.
Re:Still one of the best "I-was-there" books (Score:2, Informative)
I have read this book. But that means absolutely nothing, because the upper management of my company has not read it. We're making every mistake Brooks wrote about in MMM. We're even making mistakes written about in NSB.
We're making mistakes Brooks never dreamed of, because Brooks didn't write in a time of offshoring development. We have a CEO who truly believes that two inexperienced developers twelve time zones away are more productive than one experienced developer in house.
Brooks and Agile development (Score:3, Informative)
...not everything... (Score:2, Informative)
Like many great works, Brook's discription of the problem is excellent, but his attempts to solve it are not all perfect. Thus, I would not hand it to a manager to read without some preface to it.
____________________________________________
Re:Am I the only one... (Score:1, Informative)