Notes for the Mythical Man Month

notes_for_mythical_man_month_ch01.md

The Mythical Man-Month

1. The Tar Pit

The goal

• Program
  • A complete product to itself, ready to be run on the system it was dev'd on
• Programming System
  • 3x more costly than a program
  • Collection of interacting programs, coordinated in function and disciplined in format.
  • Each component is written such that each input/output conforms to a specification
• Programming Product
  • 3x more costly than a program
  • A program that can be tested, repaired, extended by anybody.
  • Usable in many OS envs, for many datasets
• Programming System Product
  • 9x more costly than a program
  • It is the truly useful object, the intended product of most system programming efforts

Joys of the Craft

• Sheer joy of creation
• Deep pleasure of making things that are useful to other people
• Fascination of fashioning complex puzzle-like objects
• Joys of always learning
• Delight of working in a tractable medium

Woes of the Craft

• The programmer must perform perfectly (typos, spacing, etc)
• Other people set your objectives, set resources and provide information
• Dependent on other people's programs which may be maldesigned, poorly implemented, imcompletely delivered, poorly documented
• Designing grand concepts is fun, finding nitty bugs is just work
• debugging has linear convergence, where the last bugs take more time to find than the first
• Products are potentially obsolete before they are even competed (seems worse than it usually is)

notes_for_mythical_man_month_ch02.md

2. The Mythical Man-Month

• Software projects often go awry for lack of calendar time compared to all other causes
  • Techniques of estimation are poorly developed -- often reflect unvoiced assumption that all will go well
  • Estimating techniques confuse effort with progress -- that men and months are interchangable
  • When uncertain of estimates, sw managers often lack courteous stubbornness to say "it takes the time it takes"
  • Schedule progress is poorly monitored -- routine practice in other eng domains are considered radical in sw
  • When schedule slips, natural (and traditional) response is to add manpower, which makes things worse

Optimism

• All programmers are optimists
• "All will go well" is the first false assumption
  • i.e. "each task will take only as long as it 'ought' to take"
• however tractable the medium of programming is, programming ideas are faulty, bugs arise, making optimism unjustified
• large programming efforts consist of many tasks, some chained
  • the probability that each will go well becomes vanishingly small.

The Man-Month

• Effort/Cost does vary as a product of people x months, but progress does not
• Men and months are only interchangeable commodities when a task can be partitioned among many workers with no communication among them
  • Generally not true of system programming
• When tasks cannot be partitioned, the application of more people has no impact on schedule
• When tasks can be partitioned but require communications, the effort of communication must be added to the amount of work to be done
  • communication effort is 2 parts:
    • training
    • intercommunication -- costly n(n -1)/2

Systems Test

• component debugging and systems test are most depended on success of previous steps
• time depends on number and subtlety of the errors encountered
• optimism leads us to underestimate this time cost

Example breakdown:

• ⅓ planning
• ⅙ coding
• ¼ component test ad early system test
• ¼ system test, all components in hand

Gutless Estimating

• When omlette is promised in 2 minutes, but isn't ready:
  • customer has 2 choices, wait or eat it raw
  • chef can also turn up the heat, likely ruining it
• False scheduling/estimation to meet a patron's desired date is much more common
• There is a need to develop and publixize productivity figures, bug-incidence figures, estimating rules, and so on
• Util estimating is sounder, individual managers will need to stiffen their backbones and defend estimates
  • poor hunches on esitmation are better than wish-derived estimates

Regenerative Schedule Disaster

Situation: 12 person-months work estimated. 3 people assigned for 4 months.

The project is behind schedule 1 month, now what?

1. Assume task must be done on time, assume that only the first part of the task was misestimated. 9 person-months remain, will now need 4½ people to meet schedule.
2. Assume task must be done on time, assume uniformly misestimated. 18 person-months remain, so 9 people needed to meet deadline.
3. Reschedule. Re-analyze size of task, re-estimate effort. Ensure new estimate allows work to be done carefully/thoroughly so that rescheduling does not need to be done again.
4. Trim the task. (Often happens implicitly when schedule slippage noticed) When secondary costs of delay are very high -- either trim it formally and carefully or watch it get trimmed by hasty design and incomple testing.

Brooke's Law

Adding manpower to a late software project makes it later

notes_for_mythical_man_month_ch03.md

3. The Surgical Team

Details an alternative team format in order to be able to organize large numbers of people to very large tasks

The problem

• productivity variations exist between good programmers and poor ones.
• Even within a group of experienced programmers, the ratios between the best and worst performances averaged about 10:1 on productivity and 5:1 on program speed and space measurements.
• Small sharp teams are too slow for really big systems.
• E.g. if a project is estimated at 5000 person-years
  • 10 people working at a 7x efficiency with 7x gain for working in a small team
  • 5000 / (10 x 7 x 7) =~ 10 years
  • Are people interested in working on this for 10 years? Is it relevant after 10 years?

In sum, need to find ways to break down large projects into team-sized problems which can then be coordinated/composed over teh scale of months rather than years

notes_for_mythical_man_month_ch04.md

4. Aristocracy, Democracy, and System Design

Conceptual Integrity

• One of the most important consideration in system design
• How much unity there is in the set of design ideas, rather than independent and uncoordinated ideas.

Achieving Conceptual Integrity

• The purpose of programming system is to make a computer easy to use
• Does so by furnishing languages and various facilities -- which are programs
• But these facilities are bought at a price -- the external description of a programming system is 10-20x as large as the description of the computer system
• Simplicity and straightforwardness proceed from conceptual integrity
• Every part must even use the same techniques in syntax and analogous notions in semantics
• Ease of use dictates unity of design, ∴ conceptual integrity

Aristocracy and Democracy

• conceptual integrity in turn dictates that the design must proceed from one mind or from a very small number of agreeing resonant minds.
• this is in opposition to scheduling demands which impose that system building needs many hands
• two ways to resolve:
  • careful division of labor between architecture and implementation
  • second is new ways of structuring programming teams
• separation of architectural effort from implementation is powerful
  • architecture -- cemplete and detailed specification of the user interface
  • implementation -- describes what goes on inside the case
• so how to balance concerns of aristocracy of creativity by architects (few) and democratizing creativity to implementers (many)
  • unapologetic that there should only be a few people to control concepts making up the direction of conceptual integrity
  • with regards to creative work:
    • architects are creative with the setting of external specifications
    • implementers are creative with the design of the implementation to meet the architecture
  • cost-performance ratio depends on implementer
  • ease-of-use depends on the architect
  • form is liberating, and the sandbox provided by an rchitecture can enhance, not cramp, creativity

What does the implementer do while waiting?

• concerns that if arch team is planning, implementers think:
  • the design will be too rich, ignoring cost of implementaiton (real risk)
  • the architects will get all of the fun work, leaving nothing for implementers (imagined risk)
    • implementation is a creative work in and of itself
  • the implementers will sit idle while plan comes (imagined risk)
    • matter of timing/phasing
    • flippant/quick answer: don't hire implementers too early
    • better answer:
      • total creative effort invovles 3 phases: architecture, implementation, realiziation -- Which can be parallelized
      • implementer can start as soon as there is vague assumptions about the manual (usage), clearer ideas about the tech, well-defined cost/performance objectives

notes_for_mythical_man_month_ch05.md

Second-System Effect