I can cite from direct personal experience. Our firm PRIME Consulting Group, Inc. began work as a contractor on a large-scale software development project with a team comprised of eight core developers, three adjunct product specialists, and from three to six customer specialists, for a total of up to 17 people. Let's just consider the eight core developers, and apply Brooks' pairwise intercommunication effort formula:
n(n-1)/2
where n is the number of team members. So with eight people, the pairwise intercommunication effort is 28 times greater than with two. Things get worse when you factor in team meetings with their many intercommunication pathways. This is important to understand because it helps shatter the long-standing and counter-productive myth that you can solve a project's resource constraints by throwing more person-power at it. Brooks writes, "Since software construction is inherently a systems effort -- an exercise in complex interrelationships -- communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule."
Project managers often forget that team communication effort involves person-to-person communication AND the training of each worker. The training effort varies linearly with the number of team members since everyone on the team has to be trained to the project's technology, goals, strategy, and tactics. (Brooks offers a very detailed and riveting deconstruction and expose about the myth of the man-month as a unit for a project's scale, see Chapter 2 for the details.)
For the next few paragraphs I will pinpoint the pragmatic highlights of the book. Keep in mind, however, that every single page contains one or more gems; this is a book that should be savored not once, but repeatedly.
* TEAM ORGANIZATION -- The organization favored by Brooks for large-scale projects is one he refers to as the surgical team (cited source: Harlan Mills). "Mills proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity." I leave it to you to study the excellent discussion on pp. 32-37.
* SOFTWARE TASK SCHEDULING -- Contrary to the notion -- common to programmers and their managers alike -- that the majority of a software task is allocated to coding, Brooks reveals the following empirical breakdown:
1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand
That's 33% spent on planning (before a single line of code is written), 50% on testing, and only 17% on code writing. Space constraints prevent me delving into the numerous observations, studies, and conclusions Brooks makes on this subject. If you're a programmer, the overall quality of your work can and will improve if you place a greater emphasis on planning (in large part, written documentation, more on this in a moment), let the code take care of itself as a function of the well-laid-out documentation, and then test, test, and test some more.
* DOCUMENTATION -- Brooks suggests implementing an entire methodology for documenting a software task. That methodology must: (1) use a consistent format and style; (2) itself be documented; (3) readily support routine -- daily if needed -- documentation updates available to all team members that use revision marks to highlight changes; (4) provide team-wide access to all meeting notes very shortly after a meeting adjourns. In Chapter 10 he lists the ideal document stages (Objectives, Specifications, Budget, and so on).
Click here:
http://www.amazon.com/exec/obidos/ASIN/
0201835959/tnpcnewsletter
If you've worked on large-scale software development projects (remember, to me "large" is three and over, or even 1-2 if you apply a specific development paradigm to your work), I'd like to hear from you.
