How do you do very quick (and dirty) estimations for coding tasks? [closed]

Answer 1

Think of a number, double it and then double it again (i.e. four times the first number that pops into your head)

When a boss says "how long to complete" a project, he means the time when it's complete and deployed live to the users. A programmer will (naturally) only think about the time needed to complete the programming (the time to physically type out the solution to the problem) so you typically under estimate.

A rule of thumb would be:

The 'first number' is the number of days you think it will take you to complete the task based on the scope of the task as just described. (But of course, you've not been told everything).

The first multiple is the extra time needed to recode after the first demo / prototype given to the boss and he says "Good, great. But can you add..."

The second multiple is the time needed to recode the recode up to the correct standard for production.

The third multiple is time for testing, documentation & deployment and all the other admin stuff you need to do to actually get the thing out and live.

And the fourth multiple is your contingency for the above.

This should give you a safe estimate. Of course, you should insist that a more thorough planning and estimation exercise.

Answer 2

Factor #1 is the unknowns, and you're right, you can't know them all. However, you'll usually know some major questions no one can answer for you at that time.

Factor #2 is the perceived difficulty and availability of tools and resources at hand.

---

Result = roughly double your estimate

Answer 3

If I am forced to provide estimates without enough time to properly investigate the subject at hand I tend to massively overestimate. The fix is almost always more difficult than I think it is going to be. If I think something will take a day then I say two days. If I say something is going to take an hour then I say a day. What I am trying to illustrate with these comments is that for all but the most mundane tasks like spelling mistakes, even a small code change can explode into a full day. For anything I think might take a day or more I double the estimate. I know it can be tough to do this. Management wants small numbers. You want to look smart and capable in front of other developer. See also Scotty Factory.

Even if you have QA team members that will test your code you have to remember that it is your job to test the code as well. Make sure to factor that into any estimate. That is something I have seen a lot of developers leave out of their estimating process.

Answer 4

I usually break the task down into a few pieces, but I don't estimate for these kinds of things in blocks of time smaller than a half day. As long as there are at least 5 or 6 pieces to the feature after breakdown I find that the errors balance themselves out for the most part (some tasks take under an hour, etc)

Of course, the minimum time division and number of pieces required for some level of comfort needs to vary depending on the problem domain - at least 5 or 6 half day chunks seems to be about right for the stuff I've been asked about lately, but that needs to be reviewed every few months.

When I'm asked to estimate on behalf of someone else, I resist a bit more and follow a similar practice with a generous padding system ("double and add x" as mentioned above is probably a good approximation)

Answer 5

In addition to the necessary breakdown : an advice I learned from the Pragmatic Programmers is to express estimates over 15 days in weeks, and estimates over 8 weeks in months ; so that the unit reflects the accuracy of the estimation. Be very careful over 30 weeks.

You can also base your estimations on similar tasks you already done.

Answer 6

If you really need very quick estimation, you can do work breakdown structure with every task for 1-2 days or smaller and after this estimate every task by providing min and max estimated values.

sum of min and max values specify interval for the whole task. This gives information abouts risks to your boss, which is always very useful.

You will obtain some interval, e.g. 12-15 day or 5-30 days - this is much more useful than 16 day instead of mentioned intervals.

It can be useful for you good book by Steve McConnel Software Estimation: Demystifying the Black Art.