Comments on Mythical Man-Month: Chapter 7

Chapter 7. Why Did the Tower of Babel Fail?

(cursory comments here, there is hardly any discussion to be made  because it is too easily true; needs to be said, but I can't really add anything).

7.1 The Tower of Babel project failed because of lack of communication and of its consequent, organization.

This is the same as noting the benefits of standards. There's having a standards, and making sure everyone uses the standard, 

Communication

7.2 ''Schedule disaster, functional misfit, and system bugs all arise because the left hand doesn't know what the right hand is doing." Teams drift apart in assumptions.

Pretty obvious.

7.3 Teams should communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings, and via a shared formal project workbook. (And by electronic mail.)

By documentation? yes, it is all needed but has the same difficulty as any documentation in that it is hard to make it follow reality once written down.

Project Workbook

This is an entirely new concept to me, but is very easily implemented using a wiki nowadays.

7.4 A project workbook is ''not so much a separate document as it is a structure imposed on the documents that the project will be producing anyway."

-

7.5 ''All the documents of the project need to be part of this (workbook) structure."

-

7.6 The workbook structure needs to be designed carefully and early.

designed how?

7.7 Properly structuring the on-going documentation from the beginning ''molds later writing into segments that fit into that structure'' and will improve the product manuals.

Document early? I guess really one should document continuously and this is just a reminder not to put it off until afterwards.

7.8 ''Each team member should see all the (workbook) mate- rial's (I would now say, each team member should be able to see all of it. That is, World-Wide Web pages would suffice.)

This device (workbook) still needs behavioral 'technoloy', people should be encouraged to use a wiki in this manner.

7.9 Timely updating is of critical importance.

duh?

7.10 The user needs to have attention especially drawn to changes since his last reading, with remarks on their significance.

Current wiki technology (MediaWiki) enable comparing, but it is of questionable facility (ain't so easy to use).

7.11 The OS/360 Project workbook started with paper and switched to microfiche.

Good for them. I remember when we had to use the chits thrown away by card readers. And no pen, just a stick and excess oil from the sides of the printer housing.

7.12 Today (even in 1975), the shared electronic notebook is a much better, cheaper, and simpler mechanism for achieving all these goals.

yes.

7.13 One still has to mark the text with (the functional equivalent of) change bars and revision dates. One still needs a LIFO electronic change summary.

The current implementation of good behavior, a version control system, takes care of this.

7.14 Parnas argues strongly that the goal of everyone seeing everything is totally wrong; parts should be encapsulated so that no one needs to or is allowed to see the internals of any parts other than his own, but should see only the interfaces.

Without reference to the next item, I find this total encapsulation questionable. Yes, data hiding is good at every level, reducing the unnecessary expense of mental energy. But seeing what is available and how other things look is a good way to learn design too.

7.15 Parnas's proposal is a recipe for disaster. (I have been quite convinced otherwise by Parnas, and totally changed my mind.)

Parnas's view has been totally vindicated by the open source movement. But Brooks brings up an interesting contradiction, that of data-hiding as a laudable goal. I'm not sure how to reconcile the two. Maybe it is that for unit construction purposes, making large knowledge necessary is undesirable, but for finding the tools you need (without knowing exact details), seeing the larger catalog is better.

Organization

7.16 The purpose of organization is to reduce the amount of communication and coordination necessary.

Just like in -programs!-

7.17 Organization embodies division of labor and specialization of function in order to obviate communication.

Just like in -programs!- 

7.18 The conventional tree organization reflects the authority structure principle that no person can serve two masters.

Reduces communication and trust complexity (trust complexity is how many varieties of similar but conflicting messages one gets. Yes, I just made that up.

7.19 The communication structure in an organization is a network, not a tree, so all kinds of special organization mechanisms ("dotted lines") have to be devised to overcome the communication deficiencies of the tree-structured organization.

Right. A single tree is too simplified for humans. More than one tree, or a network is better. But not haphazard.

7.20 Every subproject has two leadership roles to be filled, that of the producer and that of the technical director, or architect. The functions of the two roles are quite distinct and require different talents.

The difference needs to be explained better. A producer is... and an architect is...

Really, I thought he was going to say a technical architect and a human resource type manager.

7.21 Any of three relationships among the two roles can be quite effective:

. The producer and director can be the same.

. The producer may be boss, and the director the producer's right-hand person.

. The director may be boss, and the producer the director's right-hand person.

I think this is too localized to his situation. Interpersonal conflicts and connections may make this a good fit or a bad one. This is too losely judgable by scoial engineering experiments.