Book Finished: Mythical Man-Month

I just finished reading Mythical Man-Month by Frederick Brookes. It was pretty good, although a bit dry at times. It is a bit dated too although the 20th Anniversary Edition tries to updates the old material with a new chapter that includes discussions with others on the original material. Some of the points I took away from the book that I think are still applicable today for software projects are:

     - Adding people late in a project makes it late, or makes it later if it is already behind schedule. There is an initial overhead cost of training and the new worker to find their way and become familiar with the  project before they can fully contribute to the project. If you need more people, add them sooner than later to mitigate that cost.

     - The system architects and designers should stick to only architecture and designing and the coders should only stick to coding, that may you have a separation between design and implementation, otherwise implementation may influence or change the design to fit the implementation, which may cause problems with what is intended or if a decision is made to change platforms.

     - There should be as few designers and architects as possible, or at least as few people making decisions as possible, in order to preserve conceptual integrity and uniformity.

     - Communication is the hardest part about working on a team. The effort to communication and coordinate grows exponentially as the team grows in size. This means that doubling the work force will not double the productivity because the effort of communicate will more than double.

     - As much documentation as possible should be completed before any other work starts on a project. Writing documentation forces you to make decisions and ask questions you would otherwise put off or not know you had to make or ask. It is easier to implement things from the start rather than add them in later.

     - Despite the above point, the only real constant in a project is change, and so one must plan for changes to occur, not just in specifications in the project, but also for changes in the organization or the team performing the work.

     - Milestones need to have a clear and precise definition, otherwise confusion about progress may arise. If the definition is precise you cannot lie to yourself about progress and a person receiving a progress report will have close to the same understand of the progress as the person giving the progress report.

I've seen this book on a few required reading lists that some software developers have up on various blogs and website. I think it is worth a read as long as you pick up the 20th anniv. edition so you can understand what may or may not be still be applicable.