There is only one, even vaguely accurate, method that I am aware of: Experience.

No other method I've seen comes even close to the guestimate of an experienced, hands-on, developer(read programmer; coder; hacker), but don't be fooled. The experience has to be relevant.

You can have many years, or decades of experience of coding in one language, one OS, or one field of work, and yet be a total noob when it comes any other particular Lang/OS/task.

Longevity can help, especially if it includes a wide range of projects in a leader or manager role, but unless you've done something, or been a part of something really quite similar, there are no guarentees that your experience will be of any help at all.

If your tackling a task fo which you have no experience, and noone with relevant experience to reference, then the best you can do is:

1. break the task down into lots of very small items of work.
2. Do your very best to apply realistic estimates (in hours) to each of those items.
3. Total those estimates and add at least 50% and often 100% to account for:
   • integration;
   • unforeseen addition effort required;
   • spec changes;
   • delays through one source or another:
     • holidays.
     • short weeks.
     • sick leave.
     • company bingos.
     • irrelavant meetings.
4. Multiply by the "Scotty factor".

   Start with 5 and let them beat you back to 2.

Never under-estimate. Either to secure the work, or to impress the Boss. If you manage to meet your under-estimate through hardwork, overtime (paid or not) or shear brilliance; you've simply made a rod for your own back. It will become the norm and expected.

If the project is new to you and you are going to be held accountable to your estimate: Over estimate the time. Grossly. And then request a reasonable fraction of that time to produce a prototype.

If you're successful, write the prototype as if it will become the real thing but:

1. Write it top down.
2. Dummy-up the lower levels as you go.
3. Go back and fill in as many of them as you can before the deadline.
4. Stick to the deadline! Doing as little at each level as allows you to move on to the next.

   This includes:

   • Skipping pretty UI's;
   • Omitting error recovery--just die if things are wrong.
   • Ignore edge cases--use carefully selected "middle-of-the-road" data for basic functionality testing (and mid-project demos--if you cannot avoid them).
   • Ignore integrity--replicate a clean dataset for basic testing (& demos).
   • Ignore security--but bear it in mind.

     Add isAuthorised(); checks wherever seems appropriate, but dummy that to sub isAuthorised( return 1; } for getting the prototype going.

   • Go back and expand as many dummied parts as you can in the time.

When you demo the prototype (at the deadline):

1. Start by demoing clean; middle of the road data.

   Do this quickly and trivially, reserving as much time for the rest of the demo.

2. Re-run the demo, retaining the dataset from the first run, but demonstrating the flaws. The lack of integrity; security; error recovery etc.

   Place an estimate on the time required to fix each of these things. By this point you will have a much better picture of the overall problem, including what is easy and what is hard, and, what you hadn't thought of in your first estimate.

   With luck and a good tailwind, your prototype will show enough promise to encourage management/customer to accept realistic estimates for it's completion/conversion to production grade code.

Above all, be realistic.