 "A Classic on Software Project Management" | 2009-08-23 |
| - Reviewed By User: A31D2B0N48J4H7 |
| This is a classic on the topic of software project management. Although the book is quite old, it is surprising that many of the concepts discussed are still applicable to date, particularly around the people aspect. Concepts such as throwing more people onto a late project, will only make it even later meeting the schedule etc. This book is also foundational to the software engineering field and the difference between it and computer science, where the author draws some good parallels around how chemical engineering and chemistry are different. The engineering practices place a bigger emphasis on processes and ensuring consistent outcomes of quality and cost. One major drawback in the book is, because it is old, focuses a lot on resources (hardware and software) that does not apply to the same extent today, as well as the languages (higher level today). I found the book Peopleware to be superior than this one in the area of software people management. Nevertheless, this is a classic that must be read. |
| |
 "A classic!" | 2009-08-16 |
| - Reviewed By User: A13LM63WUF77BL |
This a classic work, and as valuable today as it was in 1975. It is mainly a collection of essays, each focusing a different issue in software engineering and management. The book is full of gems like "All programmers are optimists: All will go well", the famous Brook's law "Adding manpower to a late software project makes it later", "Bearing of a child takes nine months, no matter how many women are assigned" and "An omelette, promised in two minutes, when not ready in two minutes, the customer has two choices - wait or eat it half-cooked. Software customers also have the same choices."
This is a great book for project managers but this certainly doesn't mean it is any less valuable for programmers. The theories Fred. Brooks pioneered 34 years back are now fundamentals of software engineering and project management. Some essays I found valuable in particular are "The Mythical Man-Month" where author discusses managing project schedules, "Plan to Throw One Away" where author discusses the change in user requirements and how to tackle these changes. The best of the lot is "No Silver Bullet", where author compares software construction to werewolves, who appears to be normal but can suddenly turn into monsters. Here author stresses that managing complexity is the essence of software engineering. It includes gems like "Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike. If they are, we make the two similar parts into one, a subroutine. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound" and "The hardest single part of building a software system is deciding precisely what to built. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later". And it goes on to say that software construction is a creative process, the difference between good software design and great one does not necessarily depend on methods used to create the design, instead, great designs come from great designers.
There are a few essays which I didn't find very useful and it is there where this book looks somehow overrated. Anyways my only problem with this book is the language. For non-English speaker at places it becomes a tough read (though it is understandable given that it was written 35 years ago).
Summary: Highly recommended to software project managers as well as programmers. |
| |
 "Those Who Don't Know And Understand History Will Repeat It" | 2009-08-08 |
| - Reviewed By philip_heath |
It has been almost 15 years since the 20th Anniversary Edition of The Mythical Man-Month came out. Does such a work still hold meaning for today's software industry? Absolutely. Those who do not know history are doomed to repeat it. Frederick Brooks gives an excellent history circa 1975 of software development on the IBM OS/360 project. At the core of his argument is that men and months are not interchangeable on software development projects and further that adding people to a late project makes it later. The upshot of his argument comes down to two aspects: communication complexities and conceptual integrity. One could argue that the latter is constrained by the former.
I have been in the software industry for only 12 years, and I have to admit that I can only partially relate to the specifics of the OS/360 project. I never worked with punch cards, nor have I had limited access to my software execution environment. However, these are only the context of the message and not the message itself. Software development is a highly complex undertaking due to its abstract nature. Many have compared it to trying to nail jell-o to the wall.
One of Brooks keep coping strategies for this complexity is to separate the essential and accidental aspects. Many of the constraints on the OS/360 project were of the accidental nature - limited access to limited resources, programming at a very low level (i.e. assembler), etc. The essential complexity is trying to specify that which exists in the ether, and human communication is the source of much of the difficulty. As the size of the team grows, so does the number of communication nodes. Brooks gives suggestions on how to manage this problem that apply as much today as they did on the OS/360 project.
The last four chapters in the 20th Anniversary Edition are a reflection on what has changed since the original, and the thing that I commend Brooks for the most is an honest evaluation of what is still valid as well as what he was wrong about. This is the main focus of chapter 19, and without it this is not a five star book. Even if they do not have time to read the entire book, *all* leaders in software development organizations should read chapters 16-19. Yes, there have been many new developments since 1995, but the wisdom in these pages is as relevant now as it was 15 years ago. Read it. Digest it. Make it your own. Live it.
Overall: A+ |
| |
| "Out-Of-Date, But Not Obsolete" | 2009-07-24 |
| - Reviewed By sznet |
Although much of the approach Brooks advocates has been common practice in the software industry in the 30 years since the book's publication, The Mythical Man-Month remains as relevant today as when it was written. It references obsolete platforms like System/360 and Multics, and is set in a world where punch cards and PL/I were state-of-the-art, but human nature hasn't changed. The few parts that are truly irrelevant remain charming, like this comment: "The Apostle Peter said of new Gentile converts and the Jewish law, 'Why lay a load on their backs which neither our ancestors nor we ourselves were able to carry?' I would say the same about new programmers and the obsolete practice of flow charting."
This book ought to be assigned in every introductory programming course, so students will better understand why they're being asked to create modularized, self-documenting code. The burden of the extra reading will be offset by their relief at not being required to flow chart their programs! |
| |
| "Should be required reading in any CSci/Management course" | 2009-05-21 |
| - Reviewed By User: A1ZNGIXZOT5ING |
| This book, although initially written 35 years ago, still has views and opinions that are still valid today. It is amazing how far technology has come, yet how little we have moved in the management of products. Plus, having the official definition of Brook's Law is a definite bonus. |
| |
| "Expected more - borrow from library" | 2009-05-15 |
| - Reviewed By r3kb |
I expected more from this book, though I found that while there are many good points in the book, I believe that there are much more succinct ways of saying them. I found that this book was hard to follow in many ways because the author contradicts himself later in the book. I also expected more data than what was provided.
This book gets a lot of hype, some of it well deserved, but the days of mainframes and PF-keyed terminals are long gone. I wasted a lot of time reading about how programs were developed without the use of PC's today, how communications were done on paper some thirty years ago.
A part of me is glad I read the book if for no other reason than to learn how badly hardware and software development was done apart from my own experiences with punched cards, paper tape, and "walk-net" (walk it over to your programming partner).
Pragmatic Programmer is a much better book and more than covers the majority of what Brooks covers in his material, and I believe much more effectively.
The Pragmatic Programmer: From Journeyman to Master
KB
|
| |
Expedited Available
