Book: The Mythical Man Month Ch: 2 The Mythical Man Month

[moziliar]

Book: The Mythical Man Month
Chapter: The Mythical Man Month

Summary:

• The skills of estimates are poorly developed, especially when it comes to software project estimation. It heavily rely on the assumption that "all will go well", except it most likely won't.
• People often confuse effort with progress, giving rise to the concept of man-month. Therefore, project lagging => dump more manpower to make up for the men-months.
• This is all a myth, as costs vary according to the number of men and number of months involved, but progress does not.
• Men and months are interchangeable only when task partitioning involves no communication among workers (rarely the case in software development)
• When task cannot be partitioned because of sequential constraints, applying more effort has no effect on the schedule
• Even for partition-able task, should it require communication, there will be the following added burden:
  • Training (not partition-able)
    • Each worker must be trained in the tech stack, the goals, the overall project strategy, and the plan
  • Intercommunication
    • If a project involves an all-to-all communication, the effort is increased with a factor of n(n-1)/2
    • Will be worse if conferencing involving 3 or more workers are needed
• Debugging and testing are the most easily misestimated item in a software development plan due to human's optimism that "all will go well".
• Software testing is typically the last part of the schedule, and its delay is very probable and will have far-reaching secondary cost to other projects
• User can only govern the scheduled completion of the task, not the actual completion

Example:
Suppose a project is behind the schedule, there are 4 choices to recover from this:

• Assume the first part is underestimated, add more men
• Assume the overall estimate is under, add even more men
• Reschedule to accommodate the misestimate
• Trim the project so that it can be completed within the schedule

The first two usually don't work as expected, as men-months will be lost in:

• Training newcomers; one of the existing project members and the new members
• Redividing existing effort (e.g. redesign a three-men plan into a seven-men one)
• The manager will not see immediate effect from adding the manpower and will choose to add more; vicious cycle

Recall Brooks' Law: adding manpower to a late software project makes it later

All in all, the maximum number of men of a project depends on the number of independent subtasks, and the number of months depends on its sequential constraints.