The Mythical Man-Month is one of those classics you always hear one talk about and/or cite in a presentation. The original book was published in 1975 by Fred Brooks, a former IBM employee and Turing Award winner, and, as stunning as it sounds, most of its content is still valid nowadays - in fact, you’ll end noting that Computer Science is still a big mess, even after decades of existence. ;)

The most relevant idea of the book is the forging of the Brooks’ Law, which states that “adding manpower to a late software project makes it later”. Besides that, Brooks’ exposes some other interesting facts (I chose the ones that were really interesting in my opinion):

  • Schedules are hard to follow and guess. One can estimate a schedule based on previous experience, but it will never be precise enough. Code metrics are a good way to fix this.
  • Most time will be spent on testing and debugging. This is especially true on teams that do not use unit tests and similar practices. Embracing TDD (for example) can lower significantly this time.
  • Conceptual integrity is the most important consideration in system design. Things that are designed by many people usually end bad, with a conceptual disunity that can’t be fixed. A design conceived by single mind or a small number of agreeing minds (comittee) can make this avoidable.
  • Good design requires less optimization. That’s a fairly obvious: the more time you spend in design, the better the final product.
  • Plan to throw one (build; pilot system) away; you will, anyhow. The first time your use a new system or concept, it probably won’t get right. Prototyping is a useful way to avoid needless work and to try things before doing the real implementation.
  • People don’t like to share their tools, because they’re skill related. Who has never seen people refusing to share their vimrc files, for example? Nuff said. :P

Although this book is really old, it’s full of stuff that is still useful for the contemporary programmer. A must read for everyone.

Book on Amazon: