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.
Book: The Mythical Man Month Chapter: The Mythical Man Month
Summary:
Example: Suppose a project is behind the schedule, there are 4 choices to recover from this:
The first two usually don't work as expected, as men-months will be lost in:
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.