Factors of Software Estimation – Understand the Problem

Continuing on our this very recent series of Software Estimation where we first talked about Experience, now we are going to turn our attention towards the answer everyone says when their estimation is off the mark;

I didn’t understand the problem

How simple is that, understand what you are building?  When you think of a house being built, how much effort goes into the ground before a drop of concrete is poured?  Soil samples, digging – groundwork – this is what is laid when you are able to understand the problem.  Are the doors being installed when the floors have yet to be installed?  I pray they are not, but in software sometimes we tend to jump all over the place in an effort to “get” to the problem at some point.

How often have you heard;

I’m not 100% sure what to do here, but I’ll start over here and by the time I am done, I will have a good idea what to do here.

Two things are wrong with this statement; A) The developer is starting to code on something they really don’t have a grasp on and B) they are not confident that they will have a full grasp of the problem, even after having completed that work.  This is scary and what most often leads to coding and designs that started off with the best of intentions but is now just a partial design with a few hopes and dreams tied to it of maybe getting there.

When you don’t understand the problem this is where statements such as – “It should just work” – arise from, which do not elicit any confidence in those you are talking to.  Most will get the general gist of a problem and what the business needs but quite often there is a set of questions and/or steps that are just not being carried out which serve to help the developer better understand the problem.

Who is the User?

Who are you building this for?  Too often we ignore the audience which can radically change the work that we do – Are we building for the Internal IT guy with deep knowledge of a complex platform?  Are we building for the customer that can’t handle 15 text fields on their phone (even though it might work).  If you cannot articulate the end user for what you are building, then you do not know what you are building and at best you are taking a walk in the park at midnight during a power outage.

What’s the Platform?

When you’re building on a platform, the frame for understanding what you are building significantly changes.  When I code in PHP, it is very different then how I code in .NET – different IDEs, different libraries, different extensions, etc.  Whereas some might say you are now “locked in” to that platform and limited it by it, when providing an estimate I see this as the complete opposite where a piece of the unknown has been taken from me and now I know what I am working with and what I have to work within.  Think about it.  If you are estimating for the cloud or an on-premise solution (maybe the same product) your paradigm is going to shift resulting in a very different solution.

Draw it Out

As we grow as developers from newbies to juniors to intermediate to seniors we get lazy and think that we no longer need to write everything down, we have it in our head, we can start coding and get it done by lunch, etc, etc, etc.  No, no you can’t.  You might have some small successes along the way but for the big baddy problems, not a chance.  I live for markerboards and have one everywhere I do work – home, office, etc.  Draw it out, lay it out, draw the lines of communication.  That’s great that you can do it in your head, but take it one step further and now show your chicken stratch to someone and see what they think – can they read it, can they understand it, does it make sense or did you miss something?

This isn’t the end, we are only half-way there.