What he said, apart from a few differences that I've found works for me (YMMV):
1. Do ENOUGH design and requirement gathering up front. Talk to stakeholders and users. Play around with any unfamiliar technology that you're required to use. In short, get your bearings before you start estimating.
2. Extract tasks that must be done. Each task should take less than a day or two to complete - larger tasks than this are often "lumps" of work which are harder to estimate accurately. Divide as needed. Don't forget testing, bugfixing, "polish" and all that jazz!
3. Estimate each task in IDEAL hours. Ie. "how many hours would this take if I could focus 100%, no interruptions, closed office?" Another approach is to estimate entirely using relative units - go google the "Poker Planning Game".
4. Add up total ideal hours. Then multiply by a risk factor. (My absolute minimum is 20% - that's if I have a complete lock on both the technology, the requirements and ALL other significant project factors.)
5. Figure out how many IDEAL hours you actually get done each week. How much effective time do you have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week.
6. Now you know roughly how many weeks the project will take. Then take into consideration miscelleaneous external constraints. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Tweak the schedule further based on such known specific "X factors".
7. By this point you have a rough idea of when you will be done... in an ideal world. :)
Note: This is what I do for small projects or single iterations/increments in larger projects, ie 1-3 months for a few developers. Larger processes / project scopes = different techniques. Go google Agile/Scrum/other modern development methodologies. :)