Book Review: The Mythical Man-Month

I'm finally dedicating a (decent) amount of time to read books, so here comes one of the latests I've read.

Really good and as I said in the review, I'm amazed that the author wrote it 35 years ago and most of it still applies to software development and team management. Definetly worth reading!

Review

Title: The Mythical Man-Month
Author: Frederick P. Brooks

Note: Original first edition dates from 1975 (!!!). I've readed the 20th anniversary edition.

The book talks about managing software development, in form of essays. Some of this essays talk about differences of developing a program and a commercial product, why people like/enjoy programming (and what the problems of it are), the problems of estimating projects (the incorrect asumption that gives name to the book of "one man equals one month" and thus to shorten schedules more manpower has to be added), optimism vs reality, slipping schedules because of not enough testing, the problem of "small sharp teams" on large scale projects (no matter how good they are, they are too slow for really big projects) and the surgical team solution (one person does the heavy tasks, some others support), Conceptual integrity, ...

It also talks about separating architecture from implementation (separate the what from the how), the "second system effect" (over-design: as a first version of something goes well, second version gets so much "ideas" that becomes impossible to acomplish), what and how should be documented, communication and meetings handling, programmers productivity, documentation (what, when, how much, where and who), prototyping and refactoring (throwing away "the first system built"), bug fixing and testing, ...

Other topics include tools for development, debugging, testing... One chapter mentions a way of "branching" source code and using sharedrepositories back when Subversion was not even a idea... Good people take as much as possible advantage given the possibilities, even if the tools are quite limited.

Teaches how to think about real facts and not illusions; An example sentence: "Find real solutions to real problems on actual schedules with available resources" (Development is sequential, and so restricted and constrained).

Other topics that the book fantastically covers and defines are debugging (multiple categories, types and situations), testing (he recommends using "dummy objects” and faking input data, our actual "mock object” definition), incremental iterative development (based on small individual changes, maintaining changelogs), estimation problems and misconceptions (doing "problems-actions” negative meetings instead of "status-reviews” ones) or the importance of documentation in any software project (self-documenting code and both good and bad practices).

Also, there are plenty of examples, studies and even calculations/formulae, but one problem here is that samples are a bit outdated sometimes (or too oriented to system design).

Finally, this author is also famous for the essay "There is no silver bullet”, which appears in here too. The essay talks about the fake idea of thinking that there will be a "something” that will be valid for everything and ease a lot our development process. Explaining then that each project, each system, each situation is unique and thus, there is no single solution to all of them.

It is amazing how more than 25 years later the same text is valid and still true. It should be mandatory for project managers of IT companies.

Why so few companies follow this book advices then? I wish I knew...