How to know the duration of a software project

The best way to have a value as accurate as possible is to complete the software project.

In my software career, every time I managed to guess correctly the duration of a software engineering task was because I had done something similar in the past.

Estimating the duration is incredibly hard because you measure the unknown. Implementing a feature or fixing a bug means solving unsolved problems, generally unknown. This post is a great example.

This is a problem because business requires that you are able to commit to certain deadlines and can budget how much your software costs.

What we do at Bureau 14 is a mixture of “old-school” time schedule where we decide in advance what we would like to have in future releases and flexible time boxing where we say “we haven’t done a release for a while, let’s release what currently works”. We don’t impose ourselves a regular release interval as we have not been able to identify a benefit to regular releases in our case.

This requires us to have a stable master and a thorough continuous integration process. A master build is always runnable and stable (to the point that we can send a master build to a customer for testing purposes).

When a release is decided, master is branched and the branch goes through a QA process with a lot of human quality check along the way. When we are satisfied with the results, the build is copied to the release directory and we make an official announcement.