Time Estimates

Programmers are often said to be optimistic about how long a feature / software takes to develop. I am constantly reminded of how true this is.

This week I thought a lot about time estimates and why I am often wrong with my time estimates.

It comes down to the need to please the person asking for the estimate. The expectation that the person on the other end wants it done as soon as possible and giving a short enough time would make them happy. An approach I am going to rethink from here onwards.

http://dilbert.com/strip/2016-10-20

Dilbert Comics

In larger organisations, a project manager is usually involved in arriving at the final time estimate which includes some breathing room the programmer forgot to budget for. But even then most enterprise projects spill over time and over budget.

Here are some ways I am going estimate time from here on:

  • Understand the scope of the feature / software you are asked to develop.
  • List down all the small components of the feature / software to be developed.
  • Is there a third party company involved? Budget for extra waiting time for when you need some information from them.
  • Is there a new language/ tool you need to learn to get the work done? Budget for time to learn and for those moments when the new tool just refuses to work.
  • Budget for life in general.
  • Are you working on multiple projects? Budget for time when one project takes up a lot of your time, leaving you less time to work on the other project.

Scope changes are part of software development lifecycle. When there is a change in scope, communicate this with person on the other end about how it affects the previous time estimate rather than trying to get the extra work done in the same amount of time.

Sunil Shenoy @sunil
Made with