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

Answer 1

"six to eight weeks" works really well, one other thing that works is based on the data model.

Imagine the number of database tables (or similar) needed for the application, multiply that by the number of days you need to code the models, CRUD, UI , etc for each table and add between 30% to 50% of time on top of that.

Answer 2

Place finger in mouth, lick, wave in air and make up a number based on past experience. Then double it.

Really, its just experience that counts. You imagine what the task entails you doing, and you know how long it'll take you to do that. Double it for unanticipated items. This is also why you never ask junior programmers for such estimates.

Answer 3

At times like these, I remember the McKenzie Brother's rule on converting to metric: "Double it, and add thirty."

I generally come up with how quickly I originally think it will take to do a thing, then double it because I'm always under-estimating, and then add 30 for testing, depending on the units I'm using.

Answer 4

To estimate in the right order of magnitude, you need:

• no introduction of new technology or framework for the wanted feature;
• to separate your estimate in pure development time and availability of developers (and customer and tester..;
• to get feedback on your earlier estimates;
• a size of feature in your safe estimation range (not 2 times as large with 2 times more people)
• a stable development team.
• no project startup overhead.
• to only estimate for work you do yourself.

Answer 5

Think back to similar tasks you've done in the past and how long they took you.

If you've done nothing similar at all before, try to break the task down into subtasks, then each subtask down further, until no subtask is left that sounds like it will take longer than 1-2 days to prototype in the most naive possible way; if you can't divide up a task with an estimate of longer than 3 days, this usually implies that you don't really know what is involved in doing that task; do some quick research. Once everything is broken up enough, total it up, double the result and give that as your estimate.

If you don't know how to approach a problem enough to do the above, and your boss is breathing down your neck so you don't feel you can research there and then, instead try to give your boss an estimate of how long it will take you to do the research required to understand the problem enough to give him a proper estimate.

Answer 6

I personally refuse this type of thing. But then i work for myself, so i dont answer to a boss. Just a client, but its easier to make them understand its hard to do on the spot.