The Mythical Man-Month
The Mythical Man-Month

The Mythical Man-Month

Chapter 1. The Tar Pit

[A ship on the beach is a lighthouse to the sea.] —DUTCH PROVERB (Location 246)

Tags: quotes

Note: .quotes

programming product. This is a program that can be run, tested, repaired, and extended by anybody. It is usable in many operating environments, for many sets of data. To become a generally usable programming product, a program must be written in a generalized fashion. In particular the range and form of inputs must be generalized as much as the basic algorithm will reasonably allow. Then the program must be thoroughly tested, so that it can be depended upon. This means that a substantial bank of test cases, exploring the input range and probing its boundaries, must be prepared, run, and recorded. Finally, promotion of a program to a programming product requires its thorough documentation, so that anyone may use it, fix it, and extend it. (Location 267)

As a rule of thumb, I estimate that a programming product costs at least three times as much as a debugged program with the same function. (Location 272)

Chapter 2. The Mythical Man-Month

our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well. (Location 331)

Tags: estimation

Note: .estimation our estimates assume that we wont have any issues

when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster. (Location 337)

Tags: estimates, agile

Note: .agile .estimates when timelines slip we tend to add more resources which usually makes things worse

For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. (Location 352)

Note: The gaps only appear during implementation

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule (Fig. 2.2). The bearing of a child takes nine months, no matter how many women are assigned. (Location 372)

Tags: sequential, delivery

Note: when work must be done sequentially adding more people has little impact on the timelines

Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule. (Location 391)

Note: Adding more people greatly increases the communication

Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore testing is usually the most mis-scheduled part of programming. (Location 395)

Tags: testing

Note: .testing we are usually too optimist and expect far fewer bugs than the reality

For some years I have been successfully using the following rule of thumb for scheduling a software task: 1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand. (Location 397)

Tags: planning, software, delivery

Note: Planning takes up approx 30% of the overall time

Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. (Location 407)

Tags: sit, testing

Note: .testing .sit delys in system testing are particularly impactful as they come at the end of the process

delay at this point has unusually severe financial, as well as psychological, repercussions. The project is fully staffed, and cost-per-day is maximum. More seriously, the software is to support other business effort (shipping of computers, operation of new facilities, etc.) and the secondary costs of delaying these are very high, for it is almost time for software shipment. Indeed, these secondary costs may far outweigh all others. It is therefore very important to allow enough system test time in the original schedule. (Location 409)

Tags: testing, delivery

Note: .delivery .testing projects are often fully staffed near the end so delays are particularly costly

Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later. (Location 464)

Tags: delivery

Note: .delivery adding more people to a late project makes it even later

Chapter 3. The Surgical Team

The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming. (Location 487)

Note: A small highly talented team is far better than a large mediocre team

Chapter 4. Aristocracy, Democracy, and System Design

conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. In this chapter and the next two, we will examine the consequences of this theme for programming system design: (Location 600)

Note: Be consistent in the design approach

Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. (Location 630)

Chapter 5. The Second-System Effect

Chapter 6. Passing the Word

An ancient adage warns, "Never go to sea with two chronometers; take one or three." (Location 833)

Let us consider a tree-like programming organization, and examine the essentials which any subtree must have in order to be effective. They are: 1. a mission 2. a producer 3. a technical director or architect 4. a schedule 5. a division of labor 6. interface definitions among the parts (Location 1024)

Chapter 8. Calling the Shot

Practice is the best of all instructors. —PUBLILIUS (Location 1087)

Tags: quote, practice, learning

Note: .learning .practice .quote practice is the best of all instructors

I have earlier suggested ratios that seem to apply to planning time, coding, component test, and system test. First, one must say that one does not estimate the entire task by estimating the coding portion only and then applying the ratios. The coding is only one-sixth or so of the problem, and errors in its estimate or in the ratios could lead to ridiculous results. (Location 1090)

Tags: estimating

Note: .estimating dont estimate solely based on ratios to the dev effort

his programming teams missing schedules by about one-half—each job was taking approximately twice as long as estimated. The estimates were very careful, done by experienced teams estimating man-hours for several hundred subtasks on a PERT chart. When the slippage pattern appeared, he asked them to keep careful daily logs of time usage. These showed that the estimating error could be entirely accounted for by the fact that his teams were only realizing 50 percent of the working week as actual programming and debugging time. Machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc. accounted for the rest. In short, the estimates made an unrealistic assumption about the number of technical work hours per man-year. (Location 1112)