Chapter 1. The Tar Pit

  • Effort to create standalone program effort * 3 = programming system, i.e., integratedly tested with other components
  • Effort to create debugg progrom * 3 = programming product, which includes comprehensive tests and doc
  • What shipped to user is programming system product

Chapter 2. The Mythical Man-Month

  • Don’t mix effort with progress during estimation.
  • Man-month is an dangerous metric as it gives the false impression that manpower and time are interchangable
  • Rule of thumb
    • 1/3 planning
    • 1/6 coding
    • 1/4 component test and early system test
    • 1/4 complete system test
  • Hard to esitmate without hard data. Often need to have a backbone to defend again hunchs

Chapter 3. The Surgical Team

  • Given the 10x rule, 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.
  • Surgeon in the team settles the difference. The system should be the product of at most TWO minds to maintain conceptual integrity
  • Small sharp team is best for throughput but not enough output for big project
    • Solution: clean separation of architecture and implementation

Chapter 4. Aristocracy, Democracy, and System Design

  • Design of an implementation, given the architecture, should have much design creativity. Again, need clean separation of architecture and implementation
  • Architecture, implementation, and realization can be done in parallel

Chapter 5. The Second-System Effect

  • When an architect sees an estimate he disagrees with, he can either cut the design or suggest a cheaper implementation, but since this part is builder’s responsibility, the architect should:
    • just suggests and does NOT dictates!
    • accept another design that meets the goal as well
    • suggest QUIETLY and PRIVATELY
    • FORGO credit for suggested improvement
  • The second system is the most dangerous due to one’s tendenacy to over-engineer and inability/not enough data points to see which part is common and which is particular. The solution is to add people who built > 2 systems.

Chapter 6. Passing the Word

  • Manual should be written by at most two people to keep conceptutal consistency
  • Explicitly define part of architecture that is not prescribed as what is
  • Often need both formal and prose definitions, although only one should be set as standard. “Never go to sea with two chronometers; take one or three.”
  • An implementation can serve as formal definition, e.g., simulator, although this approach involves great tradeoffs

Chapter 7. Why Did the Tower of Babel Fail?

  • The communication style is more like network rather than tree
  • Producer in the team is mostly for inter-team communication; technical director inside team and mostly technical
    • Producer as the boss is better for a larger subtree of a big project. In this case, producer and technical director must see alike on technical philosophy. Main techinical issues must be talked out privately.
    • For smaller team, producer should be the technical director’s right hand man, e.g., surgical team
    • They can be the same person only when it is small 4-6 man team

Chapter 8. Calling the Shot

  • Do NOT estimate by estimating the coding effort and then multiply by 6. The error will be greatly magnified
  • Similarly, don’t extrapolate the small system/sprint effort to bigger system
  • Only 50% of an engineer’s time on paper is on programming and debugging in bigger projects (> hundreads of man hours), the rest is on interruptive tasks,vacation, meetings into consideration. Conversely, team often missed their schedule by one-half

Chapter 9. Ten Pounds in a Five-Pound Sack

  • Fostering a total-system, user-oriented attitube is among the top priorites of the programming manager. Otherwise, you may have many local optimization yet does not have positive impact on the user (common in larger projects)

Chapter 10. The Documentary Hypothesis

  • Project manager actuall need to care about only a small set of docs. These docs need to actively maintained:w
    • Only 20% is data-based, rest is communication, and this core set of docs should be enough to fit most needs

Chapter 11. Plan to Throw One Away

  • Plan to retire the current design gracefully even when you are designing for the current version - you do not want to frustrate your user
  • May need to keep 2-3 engineers as the fire brigade
  • Senior people must be ready to manage groups or building things themselves
  • Repairing/Maintanence is an entropy increasing process (although can be slow if done carefully), while building new one is entropy decreasing
  • Maintanence is at least 40% of development costs
  • Fixing a detect has 20% - 50% to introduce a new one, because even minimized fix may have far-reaching effects

Chapter 12. Sharp Tools

  • One toolmaker per team is fair, but assemble is common team just for tooling often is not productive
  • Assign shared resources in 4-6 hour blocks, shorter than that is debatable
  • Build a performance simulator, outside in, top down. Start it very early. Listen when it speaks.

Chapter 13. The Whole and the Parts

  • Common scaffolding: dummy component, miniature file (for io formating example), tools/auxillary programs
  • Release quanta should be either large and wise spaced, or very small and frequently

Chapter 14. Hatching a Catastrophe

  • Milestones must be concrete, specific, and measurable, clearly defined.
    • BAD examples are “coding”, “debugging”, “planning”
    • Good exmaples are “Spec signed”, “all test cases passed”
    • More importatnt to be sharp-edged and unambiguous than easily verifible by the boss
  • Estimate accuracy improves only AFTER project starts
    • Under-estimate does not improve much until about 3 weeks before scheduled confirmation
  • Team should expect sharp milestons from the manager. Fuzzy milestone is a DISSERVICE to the team
  • Missing schedule/milestone is a moral killer! If this one is missed, try hitting the next one!
  • The boss must distinguish between action and status information EXPLICITLY. Do NOT act on problems when it is reviewing status time
  • Scheduled date from project manager, and estimated date from line manager. Project manager need to keep track of both
  • Preparing PERT is the job of the boss and the managers reporting to him. Maybe delegated to a separate “Plan and Control” team
  • The PERT chart with its frequent sharp milestones is the basis for true status, whether coorperatively
  • This team just gathers information and has no authority, so that line-manager can focus on making decisions

Chapter 16: No Silver Bullet—Essence and Accident in Software Engineering

  • Essential complexity often grows non-linearly with size
  • The hardest part of software is arriving at the complete and consistent spec. Much of time is on debugging that SPEC
  • Grow incrementally instead of building the software. IMPOSSIBLE to come up with complete spec, even with if customer working directly with the engineers
  • How to grow great designers?
    • The best are often not the most experienced
    • Conitnous mentoring with career profile carefully kept
    • Apprenticeship, solo desigh, tech leadership, formal education, give these as different episodes
    • Let growing designers to interact with each other

Chapter 17. “No Silver Bullet” Refined

  • Motivational factor increases productivity, while environmental and accidental factors does not improve productiviey, but only drags down when it is negative
  • The complexity often stems from the organizational malfunctions. Modelling it instead of solving the problem is highly debatable

Chapter 19. The Mythical Man-Month after 20 Years

  • Even the team as small as four can have separate architect and team manager. For large teams, have a recursion of architects.
  • Architects should guess on user attributes and frequency distributions, since a survey of target user is often too expensive, but write down the explicit guess process. Better to be explicit than to be wrong
  • Success factor: quality of people » organization > management » tools or technical approaches
  • One can move missions successfully. But in every case of attempts to move projects, the new team in fact started over, in spite of having good documentation, some well-advanced designs, and some of the people from the sending team.