Why it is difficult to estimate the time cost of a software project?

Five reasons

1. Programmers are optimist, tends to underestimate the time cost.
2. Having assumption that man and months are interchangeable.
3. Software managers have less inherent courage and firmness.
4. Schedule process is poorly monitored. Technique and routine from other engineering does not work in software engineering, programming is some sense in a creativity activity.
5. When the schedule is lagged behind, more man power is added, which make the situation delay worser.

Why programmers are optimist?

The time cost of debugging and testing cannot be estimated until or after implementation. Programmer usually ignore the time cost of that.

Why we cannot estimated the time need to be debug?

Before move on to the question, we need to understand the nature of programming first. Programming is more likely human creative activities, which can be divided into three stages:

1. The idea
2. The implementation
3. The interaction

All programmers try to make sure the idea are perfect before implementation. In reality, it is impossible. The incompleteness and inconsistencies become clearly only during implementation. It means we don’t know the bugs exist before implementation. How can we estimate the time required to fix and test the bugs?

It is very difficult to have program without bugs

A large programming effort consists of many tasks chained end-to-end. Even the probability of tasks to have bug is small, the probability to have whole program bug free is vanishingly small.

Why man and months are not interchangeable

The task can be divided into four types.

1. Tasks can be partitioned among many workers with no communication among them.
   • The months required is decrease logarithmically. When there are infinity many workers, the months required tend to zero.
2. Tasks cannot be partitioned because of sequential constraints.
   • The months required is constants, independent from the number of workers.
   • Many software tasks have this characteristic because of the nature of debugging
3. Tasks can be partitioned but require communication like training
   • It is type one plus type two. The months required logarithmically decrease to a constants when number of worker increase.
4. Tasks can be partitioned but require intercommunication
   • The communication cost increase with the number of workers. The months required decrease logarithmically. When the number of workers increase further, the communication cost dominated and the months require increase with the number of workers.

Software managers need inherent courage and firmness.

Software project are difficult to estimate. When the project fall behind the schedule, manager need to have courage and firmness to postpone the deadline and explain this to the patron. A software project is difficult to speed up.

Brooks’s Law -

Adding manpower to a late software project makes it later.

Software tasks are usually type four task, the communication cost will dominated after the team grow to a certain size.

Rule of thumb for scheduling

• 1/6 for coding
• 1/3 for planning
• 1/4 for component test and early system test
• 1/4 for system test, all components in hand

The coding time is the easiest to estimate.