|
The author really knows what he is talking about. As a computer programmer, I can tell that the author is speaking from experience. And he makes his points clearly and thoroughly.
Very good book that shows how elements of Project Management in a software development project aren't terribly different from how we manage software projects today. The best part of this book is it's self-review and today's thoughts and views at the end of the book.
It may seem logical that if you estimate that your team of 20 programmers will require 10 calendar-months to finish a project, that you can double the size of your team and finish the project in 5 calendar months. Although the original version of this work was published more than two decades ago, it's still packed with advice that's relevant for software project managers and executives. The updated version includes results from later studies and reports which make it clear that the book's message is of no less importance than when it was originally written.Brooks takes a methodological look at important factors that influence the success or failure of software projects and explodes the idea of the linear man-month. Brooks shows why this common-sense view of project-scheduling does not work in reality. Furthermore, he shows that increasing the size of a project team often causes an increase in not just the number of man-months required to finish a project, but in the number of calendar-months, as well.If you manage teams of software developers, or if you're an executive in a software company, you should read this book in order to gain a more thorough understanding of the reality behind software project scheduling and management.
This book has been extensively reviewed, so what it there to add. From my perspective, two things.First, if you aspire to being a professional in the software industry and have not read this book, then you must read this book. Of particular interest are Brooks reflections on the past 20 years in this edition.And, secondly, for those that criticize this book as being outdated, I suggest that understanding the history of our profession and the fundamental concepts that Brooks discusses is essential. To paraphrase Santayana, Those who do not understand the past are condemned to repeat it.
The engineering practices place a bigger emphasis on processes and ensuring consistent outcomes of quality and cost. 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. This is a classic on the topic of software project management. 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). 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. 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.
|
