[[Ch.1 The Tarpit]] [[Ch.2 The Mythical Man Month]] The chapter discusses the reasons why estimations often go wrong, including poor estimating techniques, confusion between effort and progress, and optimistic assumptions. Uncertainty, lack of schedule monitoring, and adding manpower to counter schedule slippage can further decrease productivity due to communication issues. The man-month measure is only useful when no communication is needed between workers, and the effort of communication must be factored into the estimation process. System tests are the most challenging part of a project and should be allocated one-quarter of the time. When faced with schedule slippage, it is important to determine if the original estimate was too low locally or universally, as adding more men can be costly and communication can become exponentially harder. The number of men required is dependent on the number of individual subtasks. > In order to improve the accuracy of our estimations, it is crucial to obtain more reliable and precise productivity figures. Specifically, we should focus on gathering data about the amount of time spent on improvement, adjustment, and debugging as compared to the time spent on building. > > So for HGBI we should start labeling ticket correctly. ### [[Ch.3 The Surgical Team]] The text discusses Mills' proposal for increasing productivity by dividing large tasks into smaller segments and utilising teams of specialised individuals, similar to a surgical team. The proposed team consists of a surgeon or chief programmer, copilot, administrator, editor, secretaries, program clerk, toolsmith, and language lawyer. The text also notes that while small teams of 10x developers are preferred, even they cannot be as productive as very large teams. >If we where to do this we would need to split of the secretary and the administrator. Also we need to start having an editor. >If we where to do this, we need better communication. Our specialists are being bogged down as they also serve as surgeons or copilots.