Why are software development task estimations regularly off by a factor of 2-3?
Excellent Quora thread with many solid examples and explanations.
Developers are also the only group where they are asked to do something which has never been done before, and tell someone else how long it will take before they even know what actually needs to be done.
I actually read the answers, some are really well-thought and viable. But from my experience it’s always because of any combination of the following:
1. 30% The task definition is incomplete, vague or nonexistent.
2. 30% There is this clever manager guy, who randomly jumps in with his priceless “how difficult can it be to [insert a difficult task], I am sure you can do it in [insert an arbitrary time frame, that is obviously insufficient], have something to show me by [insert an arbitrary deadline that is half of the time frame]” comments.
3. 30% There is another clever guy, who randomly jumps in with his “while you are at it, just do [insert a random lengthy task] for me quickly, it won’t take you long” stuff.
4. 10% Other reasons.
Nikita Barsukov liked this on Facebook.
Alexey Hanin liked this on Facebook.
Tony Riviera Partially. All software developers are bad with estimations. Myself included. That is when I call myself a software developer. Usually I’m just a lazy ass :)
Zakhar Kirpichenko Task definitions are tricky. There is a lot of unknown/accidental complexity involved. 2 & 3 are more of managerial issues. Even if you work for yourself and define your own tasks without anybody else dictating the agenda, chances are, you will be bad at estimation.
It depends on the task. If the task is well defined and I know exactly what needs to be done, my estimation can be quite good, and I usually plan for unexpected complications. But when it’s like “just do something like bla-bla-bla”, the best I can do is say it will take something like an x amount of time. The worst thing about it is that I often have to explain my time estimations to people who have no clue, and it’s always like “why so long, I really wanted this done by [arbitrary date] because [arbitrary reason, sometimes dumb and usually completely unrelated to the task] :)
You can’t know exactly what needs to be done by definition. Otherwise you would have already done it before and then you can just copy it over. :)
As for explanations of estimations, I rarely do that to people who are incompetent in the area. I basically say something along the lines of “I can do it in this time. Me, I. If you want it done faster, you will need to find someone else or refine the task.” Usually works in favor of refining tasks. I have no problem with them choosing someone else though.
To give you an example, it can be something like “don’t tell me the details, just tell me how long it will take” immediately followed by “so long? can you find a way to do it sooner, I really want to brag about it to my brother when I see him tomorrow”. Seriously, a deadline based on when you wanna brag to your brother? I’m exaggerating of course, but sometimes these things get ridiculous. I also hate when I do quick or emergency tasks, get interrupted every 2-5 minutes with questions like “is it ready?” or “how is it going?”, and then offend people by honestly saying “dude, it would really take only half an hour if you didn’t call me five times in the last fifteen minutes”. The good thing is that it’s not something I have to deal with on a daily basis :)
I hear you. :)
As far as deadlines go, I am thinking more towards “release when ready” philosophy lately. In my experience, all those business things can be scheduled easier and better than technical issues. Booking a marketing initiative in 6 month and then realizing that the project is going to be delayed for technical reasons, rush it trying to complete, create a lot of tension, and then push out an unfinished product just for the sake of releasing or meeting marketing deadlines seems inefficient. Instead, working on the project based on rough, approximate deadlines and constantly reviewed priorities, until the project is ready, internally released and used, polished, and even tested on a subset of the user base seems better. Marketing initiatives and other business activities can be scheduled once the internal release happens.
So far though I didn’t have much luck convincing management of this approach. :) But I’ve only tried like twice…
I had moderate success: depending on who the management wants to brag to and when, sometimes I can convince them but sometimes I can’t :D