Book Recommendation: The Mythical Man-Month

I end up reading a lot of software engineering books for my classes at PSU’s OMSE program.  “The Mythical Man-Month” is the first assigned book in the curriculum, and for good reason.  It’s one of the seminal texts on the topic of software project management, and offers several insightful ideas.

About The Author

Fred Brooks worked for IBM in the 50’s and 60’s as a manager for their OS/360 operating system.  He’s very articulate and uses plenty of humor and interesting historical references in his writing.   Here are a few of the book’s highlights:   

Brooks’s Law

Fred’s quote "adding manpower to a late software project makes it later” became known as Brook’s Law.  He argues that just as nine women can’t make a baby in one month, additional developers don’t necessarily help you release software sooner.  This is caused by the communication and training required when adding new team members.

No Silver Bullet

Brooks asserts that there is no magical tool or methodology that will provide software engineers a 10 fold productivity gain.  He separates the essential difficulties of producing software (e.g. Complexity, Difficult to Visualize) from the “accidental” difficulties (Lack of Tools, Clunky Languages).  It’s a good concept to keep in mind with the next development fad comes along offering to solve all of your problems. 

Conceptual Integrity

The book emphasizes the importance of preserving the conceptual integrity of the system, especially on large projects.  Brooks makes the case for a single architect (or small group of architects) creating the design of the overall product.  He offers some good tips on how the people working on the big picture should interact with the engineers implementing the design.

Why Would I Read This Book?

I’m a big fan of history and think there’s much to be learned from the successes and failures of past generations.  Although this book discusses some ancient programming practices that we (thankfully) don’t have to deal with today, I think it’s a great read for anyone concerned with delivering a software product on time and under budget.

Start the Conversation with a Programming Standard

A common topic in my software engineering courses is: "How do I help my team increase the quality of our software?" There are several best practices we can use to reduce defects in our code and ensure that it has all the good "ilities" (Readability, Maintainability, Testability, etc). One of the easiest techniques is to create a Programming Standard document.

What Are The Benefits of Using a Programming Standard?

Many good things can happen when you draft up a programming standard. I think one of the best effects is that your team will start discussing best practices and quality. One or two people can create the document then present it to the group for discussion. If everyone starts abiding by the guidelines, it can add consistency to your code base, making it seem more like the work of one author. The person maintaining the code five years from now will love you for it.

Also, you may want to start doing code reviews at some point. Numerous studies show that finding and fixing defects early is much cheaper than discovering them after you release. Code reviews can help spot problems before you release to QA. If your team has already agreed on a programming standard, you can use it to evaluate code. The religious debates about curly brace placement will have already occurred, so you don't have to re-hash those discussions during each review.

How Do I Get Started?

My advice is to aim for a one or two page document. Break it up into a few sections (e.g. Naming Conventions, Comments, Error Handling). Include a brief description at the start of each section that explains why the topic is important. Try not to use too much strict language ("Thou shalt never...") and focus on general guidelines ("Avoid methods with more than X lines of code").

If you're looking for examples, the book Code Complete by Steve McConnell includes lots of checklist and well-researched rules.If you'd like to see the programming standard I created in class, send me a note.

Do you use a programming standard on your team? Is it helping?