I recently read one of the classic books on management, “The Mythical Man-Month: Essays on Software Engineering” by Frederick Brooks. It’s a quick read, and Brook’s observations are just as relevant today as they were when the book was first published in the 1970’s (the most recent edition was revised in the 1990’s).
One key takeaway: Project timelines are often dependent on a sequential tasks, each of which take a certain amount of time to complete, no matter how many people are thrown at the problem. Projects can only be broken down into so many independent tasks, and many times you can’t proceed to a subsequent step until you solve the current problem, the timeline for which is often independent of resources deployed. Hence the title referring to a commonly used, yet artificial and often misleading unit of work. A hypothetical 100 man-month software project almost certainly can not be completed by 100 programmers all working simultaneously. Put more humorously, 9 women can’t make a baby in one month.
A related corollary is Brook’s Law: “Adding manpower to a late software project makes it later”. As new staff on any project (not just software!) need to be brought up to speed, trained, and project tasks need to be divided among additional participants, the projects actually slows down even further.
Other great tidbits:
- For a typical software project Brooks recommended that you should allocate 1/3 time to planning, 1/6 to coding, 1/4 to testing individual components, and 1/4 time to testing the assembled product.
- Always do a pilot project. The chances are high that you’ll need to do two versions anyway, once you uncover all the things you missed or incorrectly designed on the first pass. So you may as well plan for the first attempt to be a positive learning experience that informs the final version. Can you say Healthcare.gov?
- Flow charts are typically useless. They take up a ton of space with boxes and arrows. Better to simply list well-labeled steps in a process and link them logically. Skip the superfluous graphics.
- “Self-documenting” code or physical projects are tremendously useful — keep all the important explanations, specifications or comments tightly associated with the code, project documents or even physical objects that need them. Don’t create (or worse, re-create) redundant or isolated documentation removed from where it’s needed.
- Project leaders should take detailed notes for their own use, and edit them (or have someone else edit them) to make them interpretable for the rest of the team. The resulting documents can become an official record of decisions made, design decisions, and an incredibly useful collection of background information. I myself have often used this technique over the years, taking my notes or web bookmarks and turning the contents into a user guide, technical notebook or collection of tools.
That’s just some of the highlights; there’s lots more!
MechanizedIntelligence 