The Mythical Man-Month: Anniversary Edition

20th Anniversary Edition
Frederick P. Brooks, Jr.

A true software development classic that should be mandatory reading for anyone entering the software development industry.

The book consists of three hundred pages split into fifteen essays that formed the original edition published in 1975 plus four new chapters that add the 1986, 'No Silver Bullet' essay and three retrospective chapters. What is so disappointing about this book is that so few of the lessons have been genuinely absorbed by the industry thirty years later.

The title chapter of the book elegantly exposes the software development project management fallacy of treating people and time as interchangeable in project planning. The chapter concludes with the now famous but still frequently ignored Brooks's Law, Adding manpower to a late software project makes it later.

The book also discusses the idea of the surgical team proposed by Harlan Mills. Rediscovered by the agile process community and re-branded as cross-functional teams, the proposal suggests that instead of organizing teams according to function e.g. analyst team, development team, test team, that teams be formed with a mix of disciplines. This means each team forms a self-sufficient software development unit.

It also argues that the team be led by a talented and experienced chief programmer. It is no coincidence that the role responsible forleading feature teams in Feature-Driven Development is called the Chief Programmer role. Organising teams this way helps projects scale up to larger size developments by reducing communication overhead and minimising the negative impact on conceptual integrity of the software caused by the involvement of so many minds

The conceptual integrity of the software being developed is a theme that runs through the first half of the book.

For those familiar with agile planning and estimating techniques will recognise in chapter eight some of the foundational analysis behind ideas like ideal days, individual velocity, and yesterday's weather. What is also interesting is the assertion that programming productivity may be increased as much as five times when a suitable high-level language is used. I experienced a similar scale of productivity boost moving from C++ to Java. I hope that in the not too distant future someone invents a programming language that does the same to the Java and C#.

Chapter ten discusses another idea that should ring true for proponents of agile software development approaches: 'Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves.'

The final chapters of the book looks back on the original content after twenty years. On reflection, the author would change two things. First, he admits in hindsight that modules (components) should not be open to every developer but encapsulated with well-defined interfaces. Here we have made progress with the mainstream acceptance of object-oriented, component-based and service-oriented architectures and design. The second change, is to his rule of 'building one to throw away. The recommendation here is to use incremental development approach instead and even discusses nightly integration builds. These days the agile development community push a similar approach although again re-branded as iterative instead of incremental and continuous integration instead of regular build.

If you work in the software development industry you really ought to read this book through at least once.