

|
The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition (平装)
by Frederick P. Brooks
Category:
Software development, Programming, IT, Technology |
Market price: ¥ 388.00
MSL price:
¥ 378.00
[ Shop incentives ]
|
Stock:
Pre-order item, lead time 3-7 weeks upon payment [ COD term does not apply to pre-order items ] |
MSL rating:
Good for Gifts
|
MSL Pointer Review:
Focusing on the human elements of software engineering, this classic offers insight for anyone managing complex development projects. |
If you want us to help you with the right titles you're looking for, or to make reading recommendations based on your needs, please contact our consultants. |

|
|
AllReviews |
 1 2 Total 2 pages 12 items |
|
|
Adam Kahtava (MSL quote), USA
<2007-01-10 00:00>
The Mythical Man-Month by Frederick P. Brooks is often referred to as the most influential Software Engineering books ever. Despite being originally published in 1975 the content remains timeless, equally valuable today.
The central theses of these essays revolve around conceptual integrity - maintaining the product focus in large systems (IBM's OS/360). Brooks touches on many other topics such as the need for a software process, how to manage a team, and the importance of distinguishing between the architecture, design, and development processes. Brooks approaches most subjects from an abstract (managerial) perspective requiring personal interpretation (reading between the lines).
"If a system is to have conceptual integrity, someone must control the concepts." (Chapter 4)
Throughout the book Brooks continually emphasizes the need for remaining analytical (objective), and his famed "No Silver Bullet" essay can be found in Chapter 16.
"Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any-no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware." (Chapter 16)
The Mythical Man-Month is enjoyable, a wealth of information, and easy to read. Some readers may be discouraged, as this book requires personal interpretation, but in doing so the book facilitates inspiration, introspection and debate. Anyone associated with the software industry (introduction level programmer through to management) can appreciate what Brooks has to say.
If you're looking for a comprehensive checklist or an immediately implemental solution then read what other authors like Steve McConnell and Robert L. Glass have to say.
"The tar pit of software engineering will continue to be sticky for a long time to come." (Chapter 18) |
|
|
An American reader (MSL quote), USA
<2007-01-10 00:00>
The original version would have been better if it documented Brooks failure when he was in charge of the OS/360 Project for one year. Brooks' background is in engineering, not programming. His observations are personal opinion, not Absolute Truth. Those who are impressed with this book appear to have little practical experience. Woe to any programmer who disputes his manager because "Brooks says so!"
This 20th anniversary edition reminds me of an old computer program that has been modified to meet new needs. Chapter 16 through 19 have been added, as if there was no need for any other changes in the earlier chapters. But many of the examples in the earlier chapters became obsolete with virtual programming, faster machines, and bigger memories. The programmers of that Golden Age are now on the beach or have gone underground. The new era of Windows and Intel, with offshore jobs, have turned mainframe programmers into a new version of 19th century whalers and buffalo hunters. As I understand it, the problems of OS/360 were due to: a new machine architecture, a new assembler language, and new people with less experience. In time these problems were overcome. Some might compare the effort to the Union Army in 1861-62,
Chapter 16 speaks of the folklore nightmares of werewolves! Is he kidding? Brooks needs to see "Abbot & Costello Meet Frankenstein, Dracula, and the Wolfman" to update his knowledge. Software costs have dropped rapidly, as the price for Windows 2000 shows. Brooks confuses mass-production with custom work. You can compare stick-built houses to modular houses, more common outside the USA they say. Software entities are complex because they use general purpose programming languages. A specific purpose language should be less complex. Another advantage of a high-level language is fewer typed characters, and hence fewer typing mistakes that can't be found by a compiler. The advantage to time-sharing is to cut delays, it also makes programming more intensive. The rest of the chapter, pages 188-203 can be skipped. There is a "silver bullet": offshore programming where programmers are rented for $30 a day compared to $50 an hour state-side. Cottage weavers were eliminated by factory production, and whaling ships by kerosene production.
Chapter 17 has Brooks' comments on replies to his "no silver bullet" concept. A silver bullet is an alleged particular solution to a specific problem. Did anyone do a field test for this solution? Perhaps a better symbol is needed? Chapter 18 regurgitates the original book in outline form with Brooks' added comments. Did you find this educational?
Chapter 19 asks about the appeal of MM-M. Perhaps it is due to its counter-intuitive claim that adding more labor to a process makes it take longer? Would removing labor from a process make it finish earlier? More new people who don't have experience reduces the average level of knowledge needed for the job. Usually more people means the job is done earlier, as in barn-raising. Talk of a "second system" implies more experience. Brooks failure to understand this suggests some personal problem. The prevention of "featuritis" is accomplished by following the needs of users according to priority. Brooks admits his advice "to throw one away" is wrong (p.265). Page 266 tells of the problem is listening to unproven fantasies. Brooks' comments on "fluidity" (p.280) seems oriented to entertainment not production ("slide presentations") The coalescence of operating systems seems similar to automotive manufacturing (who remembers marque-specific engines?) Is "software engineering" an a priori fantasy? Other engineering creates rules for mass-production (p.286). Programming practice should be concerned with the rules for efficient creation of programs. There is a picture of Brooks on page 228, another on page i. Do you see what I see? What is the usefulness of this book.
(A negative review. MSL remarks.)
|
|
|
|
 1 2 Total 2 pages 12 items |
|
|
|
|
|
|