Would you call me arrogant for retitling this book as “Mythical technology no one cares for now”? You have the right to do so. However I want to provide some argumentation for that if it please ya.
To tell long story short – the main thesis of the title, that adding people to late projects will delay them even further is mentioned in the second chapter of the book. Until the 17th chapter you’ll deal with ancient stuff about OS/360 (what the heck is that?) and IBM 1771, Machine 881295, coding languages so ancient they make Greek Gods seem modern. I have no issues with people wanting to learn from the very basics. But generally this is not effective. If you want to dig a hole in your garden you go to the supermarket, buy a shovel and do the dirty work. You won’t, however first go and buy seeds, plant a tree, watch it grow, go to the mines, prospect the ore, process it, create the shovel blade, cut your tree (same procedure for the axe by the way?), make the handle, connect the blade with the handle and…finally dig!
Yes, you could do that, but it’s just not effective. You just rely on people who create this stuff for you. It’s important to have a basic knowledge (that a shovel blade made from paper might seem as a bad idea) but still you need other qualifications for digging a good hole.
Is this post just about nagging or will there be something constructive?
It’s the same with this book – not only it gives the reader such outdated information (ok, ok, it was written few years ago, 1974), but it’s also written so damn complicated and jumps from one extreme to the other – it’s either written too general (although I’m not the dumbest person I wasn’t able to understand) or so heavily loaded with detailed information about things one one knows they even existed without even explaining it!
You see, this is the main point – if this book should be an introduction it clearly lacks all introductional features as explaining material. If this book is a summarization of some facts… well I guess it was good back then, but now I don’t see the point of it. The mythical man-month suggests that this book is about people, about working with people but it’s just a practice report from over 40 years now. I might seem to brag here often about the release date, but you know what – other authors show that this is clearly not an issue at all, just take a look at DeMarco & Lister (if you haven’t read my article about their book – just skip the article and go buy their “Peopleware”)
Let’s consider two quotes from the book:
Consider the linkage editor, designed to load separately-com- piled programs and resolve their cross-references. Beyond this basic function it also handles program overlays. It is one of the finest overlay facilities ever built. It allows overlay structuring to be done externally, at linkage time, without being designed into the source code. It allows the overlay structure to be changed from run to run without recompilation. It furnishes a rich variety of useful options and facilities. In a sense it is the culmination of years of development of static overlay technique.
The unexpectedly hard part of building a programming system is system test. 1 have already discussed some of the reasons for both the difficulty and its unexpectedness. From all of that, one should be convinced of two things: system debugging will take longer than one expects, and its difficulty justifies a thoroughly system- atic and planned approach.
You take the meaning? First quote – my wtf moments: what is linkage editor? Cross-references? Program overlays? Overlay facilites? Structuring to be done externally? There is a lot of information in this text. But is it useful?
Second quote – a hell lot of text for saying… debugging is hard?
My advise at the end, if you really want to read this book – skip chapters 4-13 and chapter 15 and 16. Just do it, you won’t miss anything you’ll require for a start of your career. Basically in chapters 18 and 19 (of the second revision) the author summarizes his own book, commenting own statements 20 years later (revision was published in 1995).
[schema type=”book” url=”http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?ie=UTF8&qid=1412691597&sr=8-1&keywords=mythical+man+month” name=”Mythical Man-Month” description=”This is the official description from Amazon, don’t come hereafter and complain – I warned you! Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.” author=”Frederick P. Brooks Jr.” publisher=”Addison-Wesley Professional” pubdate=”1995-08-12″ edition=”2nd Edition” isbn=”858-0001065793″ paperback=”yes” ]