Le mythe du mois-homme

I find that programmers seem better at coordinating work and communicating about work compared to other fields that I have experience with. The work is organized in a much more humane way than the email inbox driven hyper-active hive-mind model of other office workers so vividly described in Cal Newport’s in “A World Without Email”. In fact, programmers seem to already be living in that future utopia of an emailless world. How did it get to be this way? I think this book may have played a major role.

Despite being only a few years removed from computer programs consisting of stacks of cards, high level languages being a new thing compared to assembly language, and changesets being distributed via microfilm, this book, originally published in 1975, outlines a way of developing software that resonates today:

In “The Surgical Team” Brooks outlines the roles required in a software development shop: The surgeon/copilot (product development), the administrator (project management), the toolsmith (dev-ops), and the tester (QA).

In “Why Did the Tower of Babel Fail”, Brooks advocates for a “Project Workbook” with features that today are available in tools such as Jira and Github.

The idea of developing a MVP and iterating on it is the topic of “Plan to Throw One Away”.

“The Other Face” advocates for writing self-documenting code with meaningful names, formatting, and comments. These ideas are greatly expanded on in Clean Code by Robert C. Martin.

That said I would not recommend this book for someone just wanting to get up to speed on these topics. For one thing, I found the outdated language distracting; as the title suggests, every programmer in this book is a “man.” Much of the book is spent discussing obsolete software and hardware systems. But as a fascinating time capsule into the history of computing and the development of the practice of programming it is worth a read and still offers relevant lessons 48 years later.

Ce livre est un classique de l'informatique, dont la première édition a été publiée en 1975. Je viens de lire la seconde édition de 1995, augmentée à l'occasion des 20 ans de sa première publication.

Evidemment, c'est techniquement daté. Les ordinateurs, les langages, les ordres de grandeur (mémoire, espace disque, etc.) évoqués par l'auteur ne sont plus d'actualité. Pourtant, cela n'est pas si gênant que cela car l'essentiel de son propos porte plus sur la conception d'un système, sur l'organisation et la gestion d'un projet informatique, que sur des considérations purement techniques.

Bien sûr, les techniques de gestion de projet informatique ont elles aussi évolué depuis 1975 et 1995, mais c'est assez troublant de voir que certaines mauvaises pratiques sont toujours d'actualité. Je pense d'ailleurs que la lecture de ce livre devrait être un pré-requis pour tout chef de projet informatique ou toute personne prenant une fonction similaire. Certains enseignements de ce livre leur seraient encore utiles.

Enfin, j'ai bien aimé les chapitres ajoutés dans le livre à l'occasion du vingtième anniversaire de la première édition, dans lesquels l'auteur revient sur ses affirmations vingt ans après pour les affiner, les amender, les corriger, les confirmer, voire les contredire totalement. C'est le signe d'une certaine honnêteté intellectuelle.

This book was written in the sixties, yet, I find its recommendations and requirements for software development are just as helpful, humorous and educational in the 21st century. I still don't understand how they got any work done back then with manually teletypes, printed requirements documents being updated everyday and the like, but they still had the exact same problems we do now. returnreturnThe two things I took away most, "the more people you add to a late project, the later the project is." Along with the title of the mythical man month, is the idea "nine women can't make a baby in a month." The other point, was that whatever your estimate is for development time, you need to consider at least twice as much for validation. This is counter intuitive, you develop it once, you test it once, and that test takes less time than writing code did, but there is so much more. The covers testing for each release, it covers finding regressions later, and any other issue that may be written against that piece of code that wasn't exposed when it was first authored. These good testers make bug fixing much easier.