Learning to Estimate Development Time

When you're taking a class in computer science, the schedule is fixed.  The semester will be over on this date, end of story.  Your project will be due before the end of the semester.  Individual projects may be pushed back, but that's a rare case.  This is somewhat similar to what I'm seeing in professional programming.  Your project will be done by this date.  The difference is how the dates get set.

In class, professors set due dates for assignments.  Of all my courses, not a single professor has come in and said "Okay, you need to program a R/B tree.  When do you think you'll have it done?"  I guess I always thought that I'd be given target dates to work towards.  Until I moved into management, anyway.  Actual programming in the real world has taught me differently.  My boss is constantly asking me for schedule updates.  "When do you think you'll have component x done?  What about component y?  Can you ditch feature j and finish feature i for the demo next Tuesday?"  I've never estimated my own dates, ever.  And I must say, I'm pretty horrible at it.

I've missed every single estimate so far.  At minimum by three days.  And I'm not even working in an extended timeframe, I'm doing three week estimates max.  Thankfully, the books I've been reading (mostly McConnell and general-development MS Press books) have all stated the same thing:  software estimation ability gets better with practice.  So I don't feel too bad about it.  I've been making a bunch of neophyte mistakes.  I'm still excited about the project, and I haven't been tripling my estimates.  Learning through practice, and all that jazz.

But experience alone isn't fast enough.  I needed to take action!  What I have done is to make a table of whenever create/commit to an estimate.  If I say I'm going to have component y by day 15, I write that down.  Then I record how long it took me to finish component y.  Sadly, only one of my components is actually complete; I need to start estimating in less broad terms.  Here's a look:

Task Estimate Actual Comment
Data Access Objects 10 days 16 days Underestimated data model complexity.
Contract Component 7 days :(  
Claim Component 7 days :(  
Finance Component 10 days :( 2x  
Graphical Prettying 5 days :|  
QA Phase I 5 days :(  

The smiley faces are optional.  I find them cute and humanizing. 

Keeping track of your estimates gives you data to look back on, to make your future estimates better.  My scheme fits nicely into an excel or *erk* Google Spreadsheet.  Whenever my boss comes into my office and asks me when a component will be done, I just fire up excel and add a row.  A quick easy way to record your estimate history.  Since I'm doing it using a simple spreadsheet without using a super-complicated CASE tools, it might even be considered Agile.  I'll see how it works out.  I think by the end I'll end up being off by a factor of two in most components.  Especially considering my soft (self set) deadline for project feature-completion was last Friday.  Here's to hoping to more accuracy in the future.

Print | posted on Monday, June 11, 2007 10:43 PM

Feedback

No comments posted yet.
Title  
Name
Email (never displayed)
Url
Comments   
Please add 1 and 4 and type the answer here: