Estimating Development Time?

Sun 30 September 2012 by Garry Bodsworth
It has been a crazy week where at the beginning nothing existed and on Friday the project was demoed live with all the functionality working.  In this compressed five day lifecycle it brought into sharp clarity  many aspects of software development.  I've always been able to estimate project length but there was no science in it, I always operated on gut feeling and put in healthy margins of error. I was one of the cogs in this project but before I go into breaking down the project there were some other factors helping this development be a success:
  • Someone leading the project who made sure requirements were locked down and made sure there was no feature creep (within reason).
  • Testers were on from day one, planning how to test and then seeing through all manner of test regimens.
  • Working with smart people.
  • Good tools for source code management, documentation, and bug tracking.
The thing that was really scary for me as a project was how my time broke down:
  • 1 day coding
  • 2 days integration
  • 2 days testing and polishing
The critical aspect here is I spent one day out of five working on pure code and design.  This should be apparent to developers that coding is not the only task in delivering software projects.  By getting something that was working in half a day also gave other people something real to code against rather than trying to hope integration would happen.
The next bit was two days of integration, this involved tidying up the code for deployment, working out installers, dependencies and so on.  Then also it was a case of working out how all of this will work seamlessly for the end user.  This also involved working out how certain bits of the operating system would work when you don't have user contexts to depend on that run as administrator, because after all most devs have their machines configured like this.  Having this installer is critical for running proper end to end tests and ensuring the end-user will get the best experience.
Then we've got testing, this is unit-testing (well actually not a lot of that in a way), functional testing, and integration testing. On a tight deadline some of this is manual and not fully automated.
In amongst all this it was a case of making sure documentation was available for all aspects of the project, from end-user, through development and API right through to testing documents and lists of tests.
I suppose this thing that people reading this is if you work out how long it will take you to code, multiply that by five.