Rating: Summary: "Adding manpower to a late project makes it later" Review: Almost everyone who works on projects with the IT industry is familiar with Brooks' Law (cited in the review title). But all too few people have read this seminal book on project management and software engineering. Containing resources such as an explanation of Brooks' Law, an incredibly useful breakdown of what kind of documentation should accompany a product, and the new chapters which examine what's changed since the book was first released. The whole world would be saved a great deal of chaos if beginning project managers would start with this fine book.
Rating: Summary: An obsolete classic Review: This was one of the most valuable books in its day (1975). It revealed huge mistakes in one of the largest programming efforts ever, and suggested mostly-reasonable improvements.But software engineering has advanced a lot since then, even if the software industry hasn't. For example, Brooks' sole team-level improvement is the suggestion to use Harlan Mills' chief programmer teams, while many such improvements have been found since then. And Brooks entirely ignores the main defect of the chief programmer team---the difficulty of finding chief programmers! (As an aside, a chief programmer team works fine now with a chief programmer, a college grad, and modern tools. Code ought to be written so a college grad can maintain it, and this approach helps ensure that. The college grad can also flesh out test cases and support in other ways. But there's still the problem of finding the chief programmer...) Brooks approach is generally, "We did that wrong. We should have done it this way, for these logical reasons." But there are often several solutions to a problem, all having logical reasons. Empirical data is needed to choose between them. Brooks rarely mentions alternate solutions, and almost never offers emperical data. A far more valuable book is Steve McConnell's "Rapid Development". This well-researched and organized book quotes data to confirm problems, discusses solutions with associated emperical data, and recommends solutions.
Rating: Summary: Great book Review: The book is really good at explaining the various aspects of the software engineering process and the concept of the mythical man month. It uses interesting examples (more related to hardware specifications and sometimes not even IT examples) to explain the requirements, design, etc phases in the SDLC. Good book!!
Rating: Summary: Must Read, and Apply for Project Managers Review: This is one of the best books , I have read on sw enginnering/project management. Contains the wisdom of project management. I highly recommend this book for Project Managers to read and apply in their day-to-day decisions.
Rating: Summary: highly recommended Review: this book is amazing as, unlike most other related books, it transcends time boundaries. the examples and ideas can be applied to any form of management. highly recommended, very easy read too.
Rating: Summary: Tame the software beast... Review: I was initially sceptical that a book on software engineering written twenty-five years ago could still be relevant today. It is. This short, concise book contains a handful of highly insightful essays, each focusing on one main topic, usually a problem area in software engineering, and possible ways to solve it. Brooks doesn't waste pages of space in excess verbosity. He just says what he thinks, and why he thinks it. It's a very underrated writing technique. The new chapters in the anniversary edition serve to acknowledge changes that have occurred since the original edition, and while there have been some, on the whole, most of the original text still stands. If you are in the field, or want to get into it, read this book. Simple.
Rating: Summary: Massively Influential, and Yet... Review: "Throwing more programmers at a project won't get it finished quicker." We've all heard it a thousand times. This is the book of the quote. This has been a massively influential book and yet we still see ourselves and others making the same mistakes in software development, year in year out. It is certainly one of the 'must read' books that every project manager should read early on in their career. Written by an experienced manager, pretty much everything it says is common sense, yet it is only common sense after you've read it. Reading the book though is only the first (and easiest) step. The hard part is putting it all into practice in the real world. To do that properly it is not enough to say that you once read it 20 years ago. It needs to be on the shelf by your desk and dipped into now and again. There's nothing so helpful as being told what to do, or not to do, (even when you already know) for contributing to the courage to go and do it. Stick by the principles of this book as far as you can and you won't go far wrong. Serious software development will never be without its headaches but that's no excuse for not doing things better. "Be the change you're trying to create." - Gandhi
Rating: Summary: Great resource for justifying development tools Review: I read the first edition when it was first released and I've been quoting from it ever since. Topics first brought to light by this book and still highly relevant today include the concept that good software tools will always save you time, money and staff, and that productivity for software engineers is inversely proportional to the amount of administrative work they need to do. Read this book whenever management wants to save money by scrimping on your development environment.
Rating: Summary: A to Z for software manament is here Review: I was very fortunate to have this book read while I managed my first project. It helps programmers and managers to come out of notion that the delays and failures are integral part of software engineering process. This book presents a good material for the desiners of the Project Management courses. On the other hand those who want to attend project management courses and buy project management tools must read this book first. It contains very smart quotes and helpful examples.
Rating: Summary: Must reading, but too seldom read Review: In giving testimony before Congress a few years ago on IT issues, I said the following: "Humanity has been developing information technology for half a century. That experience has taught us this unpleasant truth: virtually every information technology project above a certain size or complexity is significantly late and over budget or fails altogether; those that don't fail are often riddled with defects and difficult to enhance. Fred Brooks explored many of the root causes over twenty years ago in The Mythical Man-Month, a classic book that could be regarded as the Bible of information technology because it is universally known, often quoted, occasionally read, and rarely heeded." I have been involved in software engineering for over 25 years, have written many articles and even a few books on the subject. Yet every time I think I've discovered some new insight, chances are I can find it tucked away somewhere in The Mythical Man-Month. And the tarpits and other dangers he lays out plague the IT industry today. I wonder when we will grasp and apply the fundamental insights that Brooks, Jerry Weinberg, and others laid out nearly three decades ago. ..bruce..
|