Calling Shots

How much effort is required to complete a project? How long will a task take? These are the questions that everyone thinks about almost every workday.

For software project estimation, the most commonly employed technique is to estimate the coding portion and then apply the ratio to the other activities. Next, we sum up the estimates for all components and voila, we have the estimates ready to be served.

Below are 3 traps of this approach:

1. Coding is just 1/6 of the problem and applying the ratios to the rest of the tasks can not always be the right approach.
2. Even for the coding effort, the programming and debugging time is only 50% of the story. Downtime, higher priority unrelated tasks, meetings, documentation, company business, sickness, personal time, etc, account for the rest.
3. In case there is a large number of tasks/components involved, summing up the effort does not give you the right effort.

Extrapolation of 100m dash shows that a person can run a mile in under 3 minutes and that sounds super human. Similarly, we can't just sum up the estimates for all the components. As the number of components increase the interactions between components and team members increases to an exponent of 1.5

Now a question for us to think about, if a project with a large team size takes a large number of months. Does it mean the project was complex or was it because more people were assigned to it?

This 8th instalment of the book, The Mythical Man-Month, is still as relevant as it was in the 1970s. Estimation is and will remain the most debated part of a project. Some people will think an estimate is more and some will think it is less. No matter how scientific or data-driven we make our estimates, it will always be a "guestimate".