How can a Developer Estimate Times?

SubliminalVortex wonders: "Many times in the past, I have been asked on 'how long' it would take to implement a certain features/fixes in a product. What's interesting is that many times, certain 'fixes' is adjusting the wording/placement of the items in question; in other cases, users want the product to do everything they ever imagined, since it already started by following their line of thought. From there, the problem continues. From the user interface, people 'imagine' and think that 'oh, it would be easy if...' and scenarios occur, not only internally from the company using the product, but the clients themselves. Usually, several good ideas are there, but estimating times is a pain in the arse if you have a platform you're writing code for which has no documentation. How do coders estimate times to their bosses? If I know the answer outright, I'll give it, but in some cases, I don't how much time I'll take from other developers *because of the lack of documentation*. I'm going to have to bring in my D&D dice next week just to start."

Comments

Be Honest

[bhmit1]

As others have said, you should estimate based on similar tasks, and then overestimate before giving that number to management. But there's also something to be said for being honest. Most management types I've dealt with are just fine when you say "I don't know if the application allows us to make that change quickly, so let me do some research and get back to you tomorrow with an educated guess." It helps if every so often you come back to them before the end of the day and say that it was an easy change and you've already finished it. Finally, when working on more than a few things at once, I make sure there's a prioritized list that I'm working from that management is aware of (so they understand why the latest request will take more time) Also, I make sure there's regular progress on one or more high priority items. Management and customers always sleep better when they see forward momentum even if the deadlines slip a little. Spending a week with nothing to show makes them nervous even when things are on time.

Big or small changes?

[Michael Snoswell]

For small changes you can generally guesstimate from exerience with that system. If you know the code well there's a better chance of being accurate. If you have to wade through someone else's code you don't know then be very generous (generally double your guess).

With all but the most trivial changes you need something in writing to confirm what is wanted - even just an email to restate what you talked about and put your estimate in writing. Get in the habit of this. You can talk about it then look at the code for 30minutes and make a far better estimate than being pressuried into giving an answer straight away.

On much larger projects the time spent on actual coding gets less and less and the time spend on specifications, prototypes, testing, documenting, reviewing etc gets much bigger. I recently worked on a $250m sw project where coding was about 20-25% of the time. It depends on what the code is for. Normally coding is about 40% of a project but the more critical a system the less time spent on code and the more spent on design and testing. I've worked on some safety critical systems (ie where someone dies if your code is wrong) and coding was about 10% of the project. This might take a lot of joy out of being a programmer but it pays to get it right!