Factors of Software Estimation – Experience

Ask anyone in any field how long it takes to accomplish a task and you would hopefully get something of a straight-forward response in a decent amount of time.

Ask a Software Developer how long it takes to code X and you’ll probably be graced with a number of questions that could include, but not be limited to;

• Have I ever worked on this component?
• What language am I using?
• Do I know this language?
• Is this a hard problem?
• Do I know the platform?
• Do we have requirements?
• Is this a high-priority?
• When does it need to be done?

And the list can go on… and on… and on… you get the point though – estimation in software development is not an easy thing to do.  This topic is much too large for one post, so I’m going to break it into a few sections for this week, the first being Experience.

Experience plays a critical factor in task estimation, after all, it’s our experience that answers the questions – Have I worked with this component before?  How long have I been a developer?  Am I a beginner in language Y or a Guru?  A colleague of mine once performed an experiment to prove not only how complex but how far apart management is from a developer’s estimation.

He did the following;

• Asked the developer who was most intimate with the component for their estimation on the task to be completed.
• He, the manager, provided his own estimation.
• Asked his Director for an estimation of the same piece of work.

The Director was way under, the Manager was way over and the Developer was closest to the target.

What does this mean?

There exists a direct correlation of what can be achieved where the person most familiar with that area of code (through experience) will most likely provide the most accurate estimation.  Experience is that piece of data that prevents us from over-estimating a task that could normally take 4 hours into a black-hole of 28 hours because we have no idea what we are looking at and how it was built.

How can we help Lack of Experience in Estimation?

As managers and leaders, our role is to challenge an estimation that sets off alarm bells in our head.  In these cases the onus is on us to leverage our own Experience and help out (say a Junior Developer) to show them what they have missed as opposed to sitting back and thinking – “this is going to be interesting, let’s see what the kid can do“.  That’s not helpful, really its not, instead you’re adding unneeded pressure to something that probably doesn’t need pressure added to it.  It is crucial not only for the project but to the growth of the Junior Developer to understand what they have missed and guide them in what needs to be added for their estimation to be complete.

In our scenario, was the manager over compensating for experience with this developer who sometimes liked to rush things to get them done and have a high-level of bug returns?  I don’t know.  Was the Director allowing Business Conditions to enter his train of thought that skewed his estimation?  Again I don’t know.

What I do know is that the next post on Software Estimation will be about Knowledge.