review - the mythical man month

I've owned this classic, written by Dr. Frederick P. Brooks, for a number of years, and given my increased support of software development and interest in project management, I've decided to crack down on myself and read it....

Having worked in a traditional engineering field (nuclear) and in computer software projects, I have some feel for the contrasts between them. Certainly, there's a can-do optimism in writing software that I found missing in nuclear engineering, the latter being marked by ensuring that all personnel are properly trained and by strict adherence to procedure. This sense of optimism leads to undercounting the time required to perform tasks such as program planning and debugging/system test. I've been able to approach work programming tasks more systematically through using PM tools such as smooth projects and by applying project management principles to software development. But, it's still a challenge to get a rigorous planning process in place; in fact, the changes in software (new scripting languages, web services) since the anniversary edition (which is the one that I'm reading) was released in the mid-1990s have made on-the-fly development of usable services much easier.

In terms of building a team: Brooks' surgical team analogy makes sense to me, based upon my most recent development management and coding efforts in a major project, on behalf of the Northwest Digital Archives. In summary, there's a need for integrated knowledge of project development; this stands in contrast to a system that emphasized task division. As the author notes, the surgical team model "ensures the conceptual integrity of the work" (35). As far as the inclusion of "non-professional" secretaries (this book is definitely dated) on the team: I can't even picture myself working on a team with secretarial help available. Ironically, given the hybrid print/digital environment that we work in, help with managing filing systems is probably needed now more than ever.

In chapter 4, Brooks continues with the IK argument, noting that "the conceptual integrity of a system determines its ease of use" (46). Translation: implementers implement; the integration their scattered suggestions into the design can do more harm than good. Plus, as the author notes, the implementation task could then be given short shrift. There's a classic discussion on pages 47-50 that really illustrates the "mythical man month" argument, and why assigning large teams to assist system architects is so appealing on the surface. In reading it, I thought of an API as an analogy; as an implementer, I can be productive while programming while "working within a given external specification" (48). Undoubtedly, I, along with other implementers, can see defects in the API that need to be fixed. However, the elegance of the API's properties and methods is made possible by the small architecture team at the center.