Paul Jones, Director of MetaLab, University of North Carolina believes that “the Mythical Man-Month” by Fred Brooks is “kind of bible for software developers.” The book has a blend of software engineering facts and thought-provoking opinions and with these ingredients Brooks offers helpful insight for anyone managing complex projects. Brooks in his book very articulately asserts that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity. The book worked as a guideline for me throughout this semester and helped me and my colleagues manage the project that we are working on. Most of what I read in this book did not come as a surprise, since I had experienced most of that while doing real software projects. Regularly reading the book made me aware of the pitfalls the might suddenly appear during the progress of a project due to a variety of reasons. It also warned me that if something does not get done in a certain (timely) fashion then the project as a whole could fail.

Me and my colleagues tried our best to follow some of the most relevant ideas presented in the book. We realized the need for communication, i.e. “the need for teams to communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings (meeting once every week outside of class), and via a shared formal project workbook (the course webpage).” Also, the idea of maintaining official documents about the project was very convincing and we are working on that while working on the other aspects of our project. Another idea that was very striking was that of controlling a big project on a tight schedule by having a schedule, made up of milestones and dates for them; we created a schedule for our project (although at a later date) that indicated to us the lags and the leads in the project, and helped us figure out what part of the project needs immediate attention and what part of the project looked good.

There were some other very interesting observations in the book - the programmers who really think they found the last bug mess up the planning (since they didn’t); the last 10% of a software project takes more resources to complete than all used so far, i.e. the first 90% of the project takes the first 90% of the time and the last 10% of the project takes the last 90% of the time; adding resources to a late project will only make it finish even later (Brooks’s Law).

Software systems are perhaps the most intricate and complex (in terms of the number of distinct parts) things man makes. Brooks’s claim that the tar pit of software engineering will continue to be sticky for a long time to come sounds reasonable. I also agree with Brooks’s main argument in the book that no “silver bullet” will be invented that can decrease the time to perform a complex software project significantly.