The Mythical Man Month - Summary

Following are the causes identified behind the failure of software development:

Other causes of software development failures are as follow:

• Optimism:

It is the belief of the programmers in software development process being easy while ignoring any possibility of errors  that may arise from the process. These errors may be due to either external issues or due to the work done itself.

Bugs are the result of faulty ideas. An assumption of "all will go well" leads to a possible negative effect on the schedule. The project may go as planned if as the probability distribution for encountered delay exists and "No Delay" has a finite probability. A large programming effort may consist of many tasks that might be interlinked which exponentially decreases the possibility of a successful software project development, as the probability of success is highly dependent on the successful development of each of the components itself.

• Man-Month:

When it comes to required labor and schedule for the development of the software, a set of faulty reasoning is used in the effort of estimation.

Total Cost = Total number of Men x Total number of Months

In reality, progress is not equal to the equation above !

The size of the job cannot be measured from the Man-Month measuring unit  as it considers Man and Month being interchangeable units. It is possible only if the task can be divided among the workers and does not require communication; which is not true for systems programming instead is possible for physical tasks such as farming.

Task being sequential requiring constant communication cannot be partitioned thus more labor applied to it cannot result in the completion of task before schedule i.e.

Progress = 0 (with respect to increase in labor)

Therefore such tasks should also be added to the amount of work done.

The communication taking places in software development houses are of 2 types:

• Training:
• For use of new technology.
• For understanding the goals of the effort.
• For the derivation of an overall strategy.
• For understanding the plan of work where it cannot be partitioned. Where this effort becomes directly proportional to the number of trainee workers.
• Intercommunication:
• Each part of the task should be separately coordinated with other parts. Thus resulting in an increase in effort such that:

Effort=(n(n-1))/2,Where n=number of workers

An increase in labor increases the delay time in the schedule which as a result lengthens the schedule.

• System Test:

The factor affecting the schedule the most are the system tests and system debugging. Time taken during the system tests and debugging is directly proportional to the delicacy or sensitivity and the number of encountered errors. Theoretically (due to optimism) this number should be ZERO, assuming that the number bugs estimated are smaller to the actual number of bugs encountered.

Result: Testing Phase is the most MIS-SCHEDULED part of the system programming.

Thus the cost of delay will be very high if the project is fully staffed and the cost per day has reached its maximum value. The software is to support other business efforts i.e. shipping of computers and operation of new facilities etc. It is also known as the "secondary cost" which is the highest as compared to the rest of the cost. To avoid it a proper schedule should be devised for software testing. Schedule troubles are only encountered at the delivery time when late delivery results in unhappy customers and higher costs of delay leading to severe financial and psychological effects. Author according to this observation proposed his own time division between tasks:

• 1/3 of total time for Planning
• 1/6 of total time for Coding
• 1/4 of total time for Component testing and early system testing
• 1/4 of total time for system testing and debugging of all its parts.

Following are the observations made by the proposed time slicing for tasks:

• One-half of the project schedule is spent on testing.
• Many projects completed on schedule until and except in system testing where not enough testing time resulted in system failure.

• Gutless Estimation:

One of the biggest mistakes made during the development of the software product is its false scheduling just to meet the patron's desired date. Such estimations lead to project development falling behind the proposed schedule. These exists no quantitative method to drive a proper schedule and cost estimation. The proposed methods are either supported by little data or are approved by managers. Lack of good estimation results in managers trying to put an effort in defending their proposed estimation for both the schedule and the cost of development. One of the proposed solutions is to identify and publicize:

• Productivity figures
• Bug incidents
• Estimation rules
• Regenerative Schedule Disaster:

There are 2 possible ways to solve poor estimation problem:

1. Rescheduling: 
1. The work according to the newly driven schedule.
2. The quality of the work will be maintained.
3. Adding new skilled labor still required training which may result in then again a false estimation. One of the reasons for this is that it may deviate the team from the actual task or the repartitioning of tasks may result in the loss of the already done tasks. 
2. Trim of Tasks:
1. This technique is the most feasible if the secondary costs are really high.
2. Managers proposition in this case:
• Trim firmly and carefully to schedule.
• Silently trim tasks by hasty designs and incomplete testing.

Conclusion:

The major reason for the failure of software products is the schedule devised for its delivery after development and testing. The following can be used to drive software development schedule:

• The total number of months required for the completion of the project is directly proportional to the sequential constraints.
• The maximum number of men required for the project is directly proportional to the total number of subtasks.