Comments on Mythical Man-Month: Chapter 6

Chapter 6. Passing the Word

6.1 Even when a design team is large, the results must be reduced to writing by one or two, in order that the mini- decisions be consistent.

I think this is all hopelessly unjudgeable because 'large' is not defined (or it is self-defining). But the concept is important; the concept of a larger number of mini-decisions is salient, thousands of small decisions in design are made either through implicit experience or by following the path of least resistance.

6.2 It is important to explicitly define the parts of an architecture that are not prescribed as carefully as those that are.

Yes, sounds good, is good, but is an afterthought. This item is intended to get you to acknowledge vagueness, acknowledge the -lack- of specification/design. In some sense this applies to the subsystem/black box already (the subsystem, to be implemented needs its own internal design hidden), but this bullet point is also about the main design, that there are parts not devolved to the subsystem that are still just not yet specified. But it's hard to know what you don't know.

6.3 One needs both a formal definition of a design, for precision, and a prose definition for comprehensibility.

 Yes, sounds good, but a problem with DRY, and ensuring correspondence between formal and informal (the usual problem with flowcharts).

6.4 One of the formal and prose definitions must be standard, and the other derivative. Either definition can serve in either role.

Or, just to convert this into total blandness, they could be done together. It is not clear that it must be one or the other. But relevant to the previous point, whichever one is thae standard and the other the derivative, one is being modified officially, and the other has to change in kind, there has to be an explicit process to remember to modify the other.

6.5 An implementation, including a simulation, can serve as an architectural definition; such use has formidable disadvantages.

What? Is a simulation a prototype? Oh...maybe he saying this is a bad thing. In 'real-world' engineering, the prototype is a proof of concept; it isn't polished but the main effect is shown to work. No one would consider actually using the unpolished version. A 'productized' version is what will actually be used

Currently, in software engineering, there is the bad habit that prototypes, initial implementations, are somehow set in stone and become a de facto standard. Now that we've seen this, we should just realize 'don't use the prototype'.

6.6 Direct incorporation is a very clean technique for enforcing an architectural standard in software. (In hardware, too--consider the Mac WIMP interface built into ROM.)

What? (I don't get the particular reference, really, the MAC was the exemplar of that practice?). Is this the same as compiling to silicon?

6.7 An architectural ''definition will be cleaner and the (architectural) discipline tighter if at least two implementations are built initially.''

 If you have an excess of resources to do something like that, sure. Maybe competing teams? That's another luxury of big companies.

6.8 It is important to allow telephone interpretations by an architect in response to implementers' queries; it is imperative to log these and publish them. (Electronic mail is now the medium of choice.)

I feel like bug reporting software is of much higher quality now than when he was writing so this point should be 'Use modern bug reporting software'.

6.9 ''The project manager's best friend is his daily adversary, the independent product-testing organization."

Adversarial evolutionary progress sounds good but might be contrary to human nature. How can this be made less antagonistic and more...ok not so negative but more constructive. Negativity is easy (and easy to be correct), but constructive criticism is hard...at that point the commenter doesn't have the resources to  make the design take the criticism into consideration.

But this could just be the start of a better testing apparatus: formal specs, test driven development, unit-testing frameworks, testing scripts.