[unfocused828]

> under-promise, over-deliver

What do I do when I'm asked how long a feature will take and the honest answer is "I don't know"? I have tried to teach myself how to create software timeline estimates; I've still not figured it out, and it seems like nobody knows how to do it.

When I tell someone that I don't know and they still press me for an answer, I usually cave and give a random guess, followed by "but I would not rely on that." I feel so dishonest lying to people's faces like that but in the moment it feels like it is the only way to get the situation to end. Should I just get a friend and practice staing steadfast in refusing to answer? Is there something I can say that isn't going to sound like I am incompetent?

[1123581321]

Use historical data (yours and/or the company's.) Find an IRC room or something where you can ask other developers how long something could take. Try writing down every small feature, or class required, or other chunk of project and multiply the length of that list by some number like 10 hours.

[jon-wood]

Learn to qualify your "I don't know"s with details of how you're going to find out. "I don't know, but here's a guess" is far less useful than "I don't know, but I can do an hour or two of research and then get back to you with a decent estimate".

[unfocused828]

The problem here is that I don't know how to generate an estimate except by actually doing the work.

[saluki]

Since you're new you might be able to get the time they have in mind by asking 'what are your expectations for this'. (keep in mind some managers aren't good at estimating development time or might try to low ball the time to see how productive you can be)

Other than that every task/spec is different. I would review the task/spec then get back with them with an estimated range of time. 4 to 6 hours/4 to 6 days and tell them you'll update them on your progress as it's completed.

Once you're working on if things are going faster complete it/test it/review the spec/double check it and then present it as things went better than my estimate.

If things are taking longer, go to them early with what is completed and an outline of items that are taking longer than your estimate and have a new estimate ready for the time to overcome these challenges and complete it.

I would say relax, be a good listener and communicator, re-read specs/requirements and make sure you're complete/thorough in your work keep them informed and you should do fine.

Since you're new try to find someone you can trust, to be your mentor, show you the ropes, help you out, bounce ideas off of, give you the lay of the office/land.

[jon-wood]

You're pretty new to the industry I'm guessing. Estimation is one of the hardest things a developer can be asked to do, and the only technique that will consistently work is getting experience so that you have similar tasks to compare the one you're estimating to.

In the meantime, try to break things down if you can't even start on an estimate - what are the steps involved in making Task X happen? Keep breaking those tasks down until you get to something you can estimate. That's what the estimation time you ask for is used for.

[distracted828]

Yea, I've only had about 4 years since I got out of school. Trying to be better able to break the task down is part of why I want to do the studying

[deeteecee]

In my own opinion, just give a personal estimate and it's fine that it's not accurate. If you think they won't be wary of that, tell them that. I don't think this is something easy to estimate even after years and years of hard programming.