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.

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.

Peoples' names in fiction and reality

Fiction writers create a world through their narrative sequences you follow a path through their speech and it little by little fills out a landscape. But when we read we're not necessarily so rational and certain ancillary, inconsequential, non-essential details unnaturally blow up into -making- the feel of the entire narrative.

For example, physical descriptions of roles in the narrative, like their manner of dress, or even things like facial expressions. These descriptions come across (in lazier fiction) as proxies for personality, counter to the advice of "show, don't tell", the author is trying to show their face, as a movie might, but they end up just telling you what the particular expression means.

And I find this annoying. Because when reading a narrative, I do try to make a mental picture of it all, but it's a but ream like and vague, not a crisp big screen photographic image.

Another distractor of the same kind is character names. "Dagny Taggert', 'Mr. Darcy', I have a hard time articulating what they mean to me (the author would say 'exactly, you read the book to find out') but that impression came from the pseudo morpho-phonological connotations of the name, before the book.

Then what about reality?. You meet someone and exchange names, 'Oh what a nice name', 'Hm you don't look like a "Frank"', 'I used to know a "Cecil" and you're just like him'. Surely there are cultural issues, exoticism, associations. But the point is, you judge the person based on their name. They didn't choose their name (well, for the most part; some choose to alter, augment, or change it entirely).

So, for the most part, if you think the name fits or doesn't, blame the parents.

Comments on Mythical Man-Month: Chapter 4

Chapter 4. Aristocracy, Democracy, and System Design

4.1 ''Conceptual integrity is the most important consideration in system design."

What is conceptual integrity? is it consistency? is it simplicity? Is it understandability by others? The locution is pretty empty, meaning anything you want that is something like 'really good stuff', or some other self-supporting, empty phrase.The more I try to pin down its meaning, the more fluid it gets. I think I have a vague idea of what it should mean with respect to software, but any rational definition of it just never seems fully right.

4.2 ''The ratio of function to conceptual complexity is the ultimate test of system design," not just the richness of function. (This ratio is a measure of ease of use, valid over both simple and difficult uses.)

I'll just continue to harp on the undefined nature...how can one have a ratio when the dividend and divisor aren't well defined. What does 'function' mean? Number of features? Define 'feature'? This is all too vague.

4.3 To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.

Totally consistent with chapter 3. Simply a repetition (given that we accept 'conceptual integrity' to be general 'software goodness')

4.4 ''Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects." (Small ones, too.)

Now -this- is an important strategy for design and is actually substantive (where many less vague concepts than 'conceptual integrity' can be assessed, like 'time' to implement', or run-time efficiency of code (this latter idea is probably made worse, but that's for another comment, which will come soon enough)). And it is entirely abstract. Works for anything. It essentially says design is recursive. you can design a single entity by splitting it into parts (however you split) and each of those parts can be also designed. the 'separation' is essentially the structured programming/OOP concept of encapsulation/modularity/black box/hidden data, all of which are aids to memory and knowledge. That design the whole so that you need to know and remember as little as possible about the insides of the parts.

4.5 ''If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology."

Authoritarian certainly. This doesn't particularly show well with open-source projects, where (naively?) there -is- no designer or master control. But this has

4.6 Discipline is good for art. The external provision of an architecture enhances not cramps, the creative style of an implementing group.

This sounds like Russell's admonition that a good notation helps with the math (that is some structure as opposed to total freedom, helps)...OK I looked for it. The quote is very relevant:

...a good notation has a subtlety and suggestiveness
which at times make it seem almost like a live teacher.

(from Russell's introduction to Wittgenstein's Tractatus)

4.7 A conceptually integrated system is faster to build and to test.

A -modular- (let's take that as the intended meaning; not a straw man, and not really what one one thinks of immediately system certainly is -easier- and then, I guess, faster to test, but not necessarily more efficient. For comparison's sake let's say the alternative to modularity is ...I'm searching for the word...something to do with 'monolithic'...how about 'monolithicity'? 'monolithicness'? 'unity'? Anyway, a monolithic system has large communication/use degree between internal implicit concepts and features, and therefore, much shorter dependency paths than a modular system,and so is more likely to have greater executional efficiencies. BUt to support Brooks's statement, if one is being modular, then each module has a much smaller and cohoerent test range and so test can be tested more easily The monolithic system -has- to be developed/designed as one entity with all element in a designers mind at once, much more likely to overload that human's ability to manipulate the design mentally.

4.8 Much of software architecture, implementation, and realization can proceed in parallel. (Hardware and software design can likewise proceed in parallel.)

If modularity in  followed and specifications of interaction between the pieces is done well, then yes.

Comments on Mythical Man-Month: Chapter 3

Chapter 3. The Surgical Team

3.1 Very good professional programmers are ten times as productive as poor ones, at same training and two-year experience level. (Sackman, Grant, and Erickson)

Intuitively, I grant that, and so am very willing to accept the data.

3.2 Jackman, Grant, and Erickson's data showed no correlation whatsoever between experience and performance. I doubt the universality of that result.

Yes, I'm sure it 'depends'. For example on specific skills like, numerical analysis or parsing or functional programming I'm sure experience helps a lot.

3.3 A small sharp team is best-as few minds as possible.

This is too vague and too unsupported by any data. Why wouldn't a larger team of very sharp minds work (working on different parts)? How about a team with sharp designers and plodding implementers? How about...well...how about just stick with 'small' (forget 'sharp' assuming that's a constant). How small?...

3.4 A team of two, with one leader, is often the best use of minds. (Note God's plan for marriage.)

- Re: marriage - WJW. I'll cut him some slack because he wrote this in the seventies. Um..actually this summary was written in 2001.

- let's just accept it for what it is. I don't doubt this is a report of his experience but could be too swayed by anecdotal evidence (one example stands out too well in his mind).

3.5 A small sharp team is too slow for really big systems.

Contradicts 3.3. So this must just be saying 'small sharp team for ...anything but a really big system (and then you need more?)'. I don't get it. I need a definition of 'small' and 'large'.

3.6 Most experiences with really large systems show the brute-force approach to scaling up to be costly, slow, in- efficient, and to produce systems that are not conceptually integrated.

 maybe. I don't have much experience with 'really' large systems or scaling up for that mattter.

3.7 A chief-programmer, surgical-team organization offers a way to get the product integrity of few minds and the total productivity of many helpers, with radically reduced communication.

Sure...I'll accept as stated.

Comments on Mythical Man-Month: Chapter 2

Chapter 2. The Mythical Man-Month

2.1 More programming projects have gone awry for lack of calendar time than for all other causes combined.

I agree. The cause is lack of connect between desire and implementation. Because of other reasons (non-repeatability inherent as a design consideration, mentioned in chapter 1). Also, it is easier to think of a thing than it is to create a thing. This is not particular to software. But maybe it is worse for software. Drawing a diagram of a building is hard thoughtful design work, but everybody can compare that directly to lifting a beam with a crane to implement the drawn line, and how much harder the latter is compared to the former. But thinking about some one else's thoughts seems makes the others thoughts seem so easy.

2.2 Good cooking takes time; some tasks cannot be hurried without spoiling the result.

This isn't special to programming. Neither really is the first one but for that I could think of programming specific reasons.

2.3 All programmers are optimists: ''All will go well.”

Again, this isn't special to programming, or even engineering, but any kind of planning.

2.4 Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation.

2.5 But our ideas themselves are faulty, so we have bugs.

faulty = inconsistent, incomplete at the best of times, but usually just underspecified, vague, and inchoate

2.6 Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.

On an assembly line, labor/time -is- a commodity, adding more people -does- make things better. Again, define what it is being added to. Adding more people to a project certainly may make things go faster, when those pieces are small, identifiable, seperate parts.

2.7 Partitioning a task among multiple people occasions extra communication effort-training and intercommunication.

No doubt. Communication costs increase with size. Software is hardly ever assembly line. Every product is new. One way to think about it is that software -is- design, you're designing an assembly line to automatically take care of many multiples of objects. Yes, you can assign more people to more sandbags, to add items to widgets. But the things that a programmer is working on...every item is a new, different thing that can't be treated in exactly the same way as the previous one.

2.8 My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.

This is just SWAG (or more charitably, what he happens to do). Even if timing experiments are done, too much is not measurable in a controlled fashion. Each of these events is 'as long as a piece of string' (i.e. however as long as it will take). Is this normative or descriptive? As percentages then meaningless.

2.9 As a discipline, we lack estimating data.

Yes. Because things are not repeatable.

2.10 Because we are uncertain about our scheduling estimates, we often lack the courage to defend them stubbornly against management and customer pressure.

I'd also add that the occupational hazard of the engineering discipline is concern for details and technical aptitude, and so a lack of practice in human psychological concerns. That's general, but also the specific acceptance of authority's wishes too easily because wishes aren't facts and so cannot be argued.

2.11 Brooks's Law: Adding manpower to a late software project makes it later.

Famous, supported by data. Depends on definitions (what -kinds- of projects).

2.12 Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication.

Yes, those are the major subparts of Brooks' law (when it applies)

Comments on Mythical Man-Month: Who the hell am I to say anything

Anybody can say anything about anything. a cat can look at a king. But you got a point, how does one trust, put weight, care about things said?


So what possible way can I justify that what I say anecdotally or with the scent of authority has any potential to be extrapolated successfully? We all have many layers of what we do: the accountant has to manage people in addition to being a whiz at adding/using excel, the plumber a whiz at knowing the hidden possibilities of where pipes go and dealing with suppliers not just how to connect PVC to iron, etc. A major part of my immediate purposeful salaried work is doing and managing software engineering: I program, and I manage other programmers. Not many programmers, and not a huge project (actually conveniently scaled), but I have to interact with a number of other IT organizations (company internal; few working contacts outside). I have worked in 'industry' just out of college but only on smallish things (one self-contained) and one that involved groups but self-contained within around 20 software types, did absolutely nothing of any use or nontrivial size in grad school.

So without a complete month-to-month CIA file biography, there it is. Not a lot of experience with large projects. But I have some experience, enough to be able to comment intelligently.

Comments on Mythical Man-Month: Chapter 1

Analysis of Brooks' bullet points from Mythical Man-Month chapter 1. (note: these will all be interlinear)

Chapter 1. The Tar Pit

1.1 A programming systems product takes about nine times as much effort as the component programs written separately for private use. I estimate that productivity imposes a factor of three; and that designing, integrating, and testing components into a coherent system imposes a factor of three; and that these cost components are essentially independent of each other.

The numbers Brooks chose (3 and 3) are wildly divergent depending on the kind of software system being developed. Is it a big system with large modular parts? Is it a small highly optimized system? Is it a -new- system? I think realistic numbers could be made with a lot of differentiation of what system means and a lot of experimentation. The primary point is that design/integration/testing are a big part of any project. I actually don't know what he means by 'productivity', but I'll grant 'independence'.

1.2 The craft of programming ''gratifies creative longings built deep within us and delights sensibilities we have in common with all men," providing five kinds of joys:

• The joy of making things.
• The joy of making things that are useful to other people.
• The fascination of fashioning puzzle-like objects of interlocking moving parts.
• The joy of always learning, of a nonrepeating task.
• The delight of working in a medium so tractable- pure thought-stuff-which nevertheless exists, moves, and works in a way that word-objects do not.

These five points are not particularly independent (1 and 2 are paradoxically not independent, and I consider 1 and 3 identical in this context of programming/systems engineering, because that is what we are making. As to 'non-repeating', the unwritten implication is the avoidance of boredom. We (programmers) will spend -hours- working on a for-all-time general solution with a one-button-press initiation to avoid having to do a repetitive keyboard operation over and over (that could easily have taken less time than the general solution). In fact, there is (read: 'I have') a visceral reaction to when others do something many times, when it is so obvious that one could do it once.

These points are really just an expression of the general motivating psychology for programmers. It is a good explanation for all the work put into 'open-source' and 'free-ware' ('see what I can do').

1.3 Likewise the craft has special woes inherent in it.

• Adjusting to the requirement of perfection is the hardest part of learning to program.

This is a bit like saying 'math takes getting used to'. Which is not to say that I disagree, it's just speaking to an audience of programming outsiders, which I'd expect is not the primary readership of this book.

• Others set one's objectives and one must depend upon things (especially programs) one cannot control; the authority is not equal to the responsibility.

I think this is simply a statement of the manager/worker/tool situation (managers ask workers to get things done, the worker/programmer attempts to do that using tools, and some of those tools may be created by others outside of one's control. I'm not totally sure about the independence of authority and responsibility set forth here. Again, it's philosophy, other views of the same situations are equally valid.

This sounds worse than it is: actual authority comes from momentum of accomplishment.

This qualification is still unclear.

• With any creativity come dreary hours of painstaking labor; programming is no exception.

True of any skill: painting, storytelling, baseball. I think he's trying to emphasize that programming, which many people are plain unfamiliar with, -is- a skill.

• The programming project converges more slowly the nearer one gets to the end, whereas one expects it to converge faster as one approaches the end.

Could be cynical, fatigue at the end making things harder than expected. But also, many design situations create a tree of resolutions needed: to resolve problem X, a number of subproblems need to be resolved, and each one of those subproblems their own. So the number of problems grows exponentially, but labor only achieves at a linear rate.

• One's product is always threatened with obsolescence before completion. The real tiger is never a match for the paper one, unless real use is wanted.

This sounds like 'whatever you make will be out of date before you get to market'. I'm sure that is a worry of any designer, and comes true all the time but it is still a philosophical statement. For example the opposite is similarly supportable; there are many products, badly designed, poorly implemented, and late (from the initial idea) that have grown and taken over market share despite those failings (Windows is the most obvious example). 

This chapter is really general motivation and psychology rather than anything much experimentally testable. It mostly rings true for me, and I highly suspect for most programmer types. 
 

Note: by 'philosophical' I think I mean 'a cogent thing, but it's opposite, and orthogonal versions are equally supportable'.

What Brook's expects for Mythical Man-Month

What Brook's expects for Mythical Man-Month's last chapter...the last chapter of his book (a recent edition/some 25th anniversary republication) is a linear bullet list of all the claims made in the original, chapter by chapter. I think his intent was to encourage what I am about to do which is take each of those points and comment: were they right or wrong, do they still hold, is it relevant at all, etc. So the first installment will be on the intro to that chapter:

Much more is known today about software engineering than was known in Which of the assertions in the original 1975 edition have been supported by data and experience? Which have been disproved? Which have been obsoleted by the changing world? To help you judge, here in outline form is the essence of the 1975 book-assertions l believed to be true: facts and rule-of-thumb-type generalizations from experience-extracted without change of meaning. (You might ask, ''If this is all the original book said, why did it take 177 pages to say it?'') Comments in brackets are new.

Most of these propositions are operationally testable. My hope in putting them forth in stark form is to focus readers' thoughts, measurements, and comments.

Ah...that's exactly what I just said I was going to do. So really, I only have one comment. Re: "Why did it take 177 pages to say it?" ...I take that as a rhetorical humor; of course it takes a book to explain a bunch of bullet points. My further comments come with the expectation is you have read the book (or if you have a question about his point, to go check the full original text...or just assume).