Comments on Mythical Man-Month: Chapter 5

Chapter 5. The Second-system Effect

5.1 Early and continuous communication can give the architect good cost readings and the builder confidence in the design, without blurring the clear division of responsibilities.

This is somewhat bland. Was it a problem in his time that communication was restricted so much?

5.2 How an architect can successfully influence implementation:

• Remember that the builder has the creative responsibility for implementation; the architect only suggests.

• Always be ready to suggest a way of implementing anything one specifies; be prepared to accept any other equally good way.

• Deal quietly and privately in such suggestions.

• Be ready to forgo credit for suggested improvements.

• Listen to the builder's suggestions for architecture improvements.

This is all about handling competing concerns: separation of concerns and managing personalities. To summarize, separate the responsibilities between design and implementation, but allow communication between the two parties.

5.3 The second is the most dangerous system a person ever designs; the general tendency is to over-design it.

Sophomoric? Most of the software engineering discipline is about managing peoples' psychology, either individuals or groups. The 'second system' problem is about what didn't get done or got done badly in the first one, and the problem is that one over compensates. or rather -can- compensate. A first system may have made compromises or limitations in an attempt to get out in time; the second system might try to correct this by adding all the features planned but missing from the first one. Or if design was haphazard in the first system, actual design used for the second, maybe just the less informal process of the second system allows more realistic performance metrics.


So this may happen, or it may not. Which is the number two system? Is it the one after the prototype? Or the one advertised second? 

5.4 OS/360 is a good example of the second-system effect.

(Windows NT seems to be a 1990s example.)

This is soooooo old. In fact nostalgic, I am not so old to...actually...I -am- barely old enough. (my only comment here is nostalgic). I remember back when I first got the computer bug (~7th grade, in the late eighties right before the first prolifereation of PCs, meaning there were none). An older friend of the family happened to be a programmer, and just happened to have a little souvenir for me: a reference card for System 360 JCL and assembly language. It was just the right amount of inscrutability to get my interest. It was an opaque totem..well I did learn about tangential things from it like the existence of EBCDIC and hexadecimal and that there were opcodes and registers and such. I didn't have a 360 to try to code on, but I did have a ...well eventually I had a 6502 to do real assembly on. And by college when I had an architecture class, and our first materials included a System -370- refcard (woo hoo...progress...looked almost the same and I already understood what was going on), I was almost jaded. But really, you just accept what things are in a class.

Which is all to say, I can't really judge his pronouncement about OS/360.

5.5 Assigning a priori values in bytes and microseconds to functions is a worthwhile discipline.

What I think he's trying to say here is 'just do it'. If you're going to try to estimate something, treat it as a Fermi problem, approximate right now without a whole lot of thought and engineering, you can fix up the details later.