Let me point out that asking an individual developer to give an estimate is probably the least accurate and effective method, partitioning or no. Books on estimation flame about it.
If you've got no historical data, a much better bet is to get a group of people to give estimates. As well as code writers, this group should include application analysts, testers, and documentation developers. If you want to get fancy about things, you can hold formal meetings using the wideband Delphi methodology. Why does this work? For the same reason, any kind of group review works; it reminds people of the things they've forgotten in their estimate. Although I don't know of any research that shows this, getting a full list of tasks probably contributes more to accuracy than the accuracy of the individual pieces. If you've got historical data, then there are a large range of techniques available, ranging from estimation by analogy up to models like COCOMO that take into account a whole range of factors, including experience of the team and memory constraints on the processor(s) on which the application will be run. There are also commercial tools such as KnowledgePlan and QSM. It's also worth pointing out that on any non-trivial problem, effort estimation is not the same as schedule estimation. To do schedule estimation you need to understand both intrinsic constraints - "this has to get written before that" - and resource constraints - "these people won't be available until this other project finishes." People who do estimation also talk about the "estimation convergence." Early estimates have very wide error bands; as the project proceeds, the estimates get narrower and more accurate. Ruven
