A few years ago my team and I came up with a term for all the shit you have to do on a software project after you’ve done what you initially perceived to be the most significant part of the job:
It derives from the fact that, when you first learn physics in high school, you are given formulae for calculating things like the speed at which an object will slide down an inclined plane and told to ignore friction (and wind resistance).
When you get to a higher level of education and start taking friction and wind resistance into account it increases the complexity of the calculations considerably.
The reason for doing this is obvious: despite the increase in complexity the same basic principles still apply and it’s easier to learn those principles initially in a simpler form.
The problem with software estimation is that when we initially look at a task, unless we have specifically dealt with a similar problem before or have extensive domain expertise we’re looking at the “simplified version” that ignores friction and wind resistance.
If we know basically *how* we would go about doing something, in our own minds, it’s as good as done. Sure there are bound to be a couple of curve balls but how hard can it be?
It’s not until the force of Friction hits that we realise the task is an order of magnitude more complex and time consuming than we first thought.
I don’t think there is any way of fixing it, either. As developers we’re expected to deal with a variety of situations in which we have no prior experience so really our only weapon in the war on undeliverable projects is to ruthlessly cull the scope of work until we’re only planning on doing the least amount of work we can.
The question I like to ask myself (and my clients) is:
“If we took this feature out of the product, would it be a different product?”
If removing a feature won’t change the fundamental purpose of the product then we don’t need to build it before we launch.
And let’s face it, “before we launch” is where most software projects fail!