Software Estimation

29 Apr 2013. comments

Software estimation has got to be one of the greatest examples of humans not learning from their mistakes. Time and time again we attempt to estimate how long our software is going to take and it’s always wrong. And usually it’s wrong by a lot. But we keep doing it.

When time and money are finite it’s important to weigh alternatives. Usually the way this happens is we try weigh our options in terms of what will have the highest impact for the time input. But complexity determines time input. And you can’t understand the complexities of software and the variables involved because they do not become clear until you are in the middle of developing the software and uncover that complexity. At the start of a project our level of understanding about the software is the lowest it will ever be, which makes it the worst possible time to estimate it.

Software is a very complex thing and as such the only way to understand how long something will take is to reduce complexity of the upcoming work. There are a few ways of doing this but it largely comes down to:

  • Breaking bigger things down into smaller things
  • Reducing the scope of the things

If you attempt to estimate anything farther than a couple weeks out you are lying to yourself and everyone involved in your project. There is just no way to do this with software because no two software projects are the same. The very reason we write software is to solve unique problems to our problem space, and therefor we can’t know how long that will take because if we did there would already be software to solve our problem because someone else would have already written it.


Tagged: agile software estimation

2017 Ben Lakey

The words here do not reflect those of my employer.