

How can you estimate time for something you've never done before? - rbsn

How can you estimate time for something you've never done before? It could be a feature you've never written before or one which you are not sure is even possible?
======
aidos
It's a complicated business. More than anything I'm very honest about the
uncertainty these days. I also try to give ranges for things - instead of
saying it will take about 2 days (which cements a specific deadline), say, 2 -
4 days.

As you get older (more experienced) you become less concerned with
overestimation. When you're young and ambitious you think that a) you can do
it faster than you really can and b) it's bad to say it'll take 2 days when
really you _think_ you can do it in 1. a) you can't and b) people don't
normally question your overestimates.

Also, try to think things through. Ask questions. Discover those subtle
missing requirements that haven't been communicated yet. Try to picture how it
will fit into the system and imagine why that might go wrong. If it's a bigger
feature break it into parts and (over)estimate each of those.

Be _thoughtful_ , _overestimate_ and be _honest_ (especially with yourself).

------
daven11
I use a very simple version of function point analysis. Write down all the
different things you know you need to do, beside each one write easy, medium
or hard. easy takes 0.5 to 1 day, medium 2-3 days, hard 3-5 days. If you think
any bits are very hard then break it down - if you can't then you've found
something you don't know - and you have to focus on that - this is a risk and
flag it as such.

If it's a big project then chop it up into deliverables, so you can monitor
your estimates along the way.

..there's a lot more but something to get you started.

(if you have to deliver on your estimate - double it :-). When you double your
estimate - make sure you don't work to your doubled estimates - otherwise
you'll have to double it again :-) )

------
EnderMB
I work at an agency using ASP.NET, so I find myself regularly estimating for
projects and small jobs. The biggest issue with our clients is that they will
always argue how long things will take. One of our large clients has a SEO guy
in one of their offices that has "11 years web experience" (despite not
programming professionally for the best part of three years, and seemingly
knowing very little about programming or how the Internet works) and he will
frequently argue every small cost. We quoted two hours to modify a form used
across eleven country-specific sites for one specific use case on a single
site, and he went crazy, stating that it'd take him "twenty seconds in PHP". A
bit of Googling shows that this guy hacks a bit of PHP in his spare time, but
can't code for shit, and given his position at the company it's not really up
to him to dictate price.

Anyway, the only way to give a valid estimate is to break down the task as
much as you possibly can and to assign risk to each small task. Build a
spreadsheet and break down every task into the smallest possible unit, and
assign a risk rating to it. Any tasks that are high risk should be estimated
as a range, rather than a fixed time. Even with this advice you'll still get
things wrong, but it's impossible not to. It's the nature of estimating.

The best advice I can give you is to stick to your guns and estimate for how
long it will take YOU to do a task. If people still argue, then tough. As
rightly pointed out by adios, more experienced devs/pm's will happily
overestimate and will fight their corner to say that this is how long a task
takes. If you are honest with yourself on how long a task will take then you
will find it much easier to stick to your guns when someone complaints that
"an easy task" shouldn't take as long as you've said.

------
shanelja
_Over_ estimate.

Yesterday I was asked to integrate Sendgrid with our analytics server over
cURL in a cronjob.

Not only had I never used Sendgrid before or even seen the codebase for our
analytics server, I've never used cURL Multi before - so I was walking in
knowing nothing.

I said it would take me "about 2 days", which seemed "fair" to my manager, in
the end it only took me about 5 hours, so they were happy to get it early and
I had all the debug time I needed.

~~~
rbsn
I try to overestimate, but then I worry that I may be seen as wasting time or
being grossly inefficient. Obviously there is a balance. This is something I
worry about much.

~~~
arxanas
If you get work done before the due date, how could it be seen as inefficient?

~~~
rbsn
My problem is that if I say it would take me 2 weeks and my colleague says he
can do it in just one - though I am overestimating, he will most likely seem a
better, more efficient employee.

~~~
kohanz
If they consistently estimate less effort than you do AND they consistently
delivers on those estimates, then they ARE more efficient. However, you will
find in most cases that the people who give lower estimates, tend to miss
deadlines more often too.

------
sharemywin
Break it into smaller pieces that you can estimate. Is there something that is
similar? You can always say let me research a little bit to get you answer. In
engineering/technology it better to under commit and over deliver. In business
it's better to over commit and work your ass off.

------
pagade
Remember and remind - Hofstadter's Law: It always takes longer than you
expect, even when you take into account Hofstadter's Law.[1]

[1] <http://en.wikipedia.org/wiki/Hofstadter%27s_law>

------
VikingCoder
Remember the first rule of data:

Never gather it, until you know how it's going to be used.

Who is asking you to estimate, and what are they going to do with those
numbers?

Until you explore and understand the answers to those kinds of questions, it's
irresponsible to try to satisfy the request.

If you like the answers you get, then give the best data you can. If the
answers you get suck, then you need to try to change how people are behaving.
If you can't, then maybe you need a new job.

