|Perl Monk, Perl Meditation|
Re: Estimating Task Complexity VS Loudmouthby BrowserUk (Pope)
|on Nov 23, 2004 at 15:57 UTC||Need Help??|
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:
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:
When you demo the prototype (at the deadline):
Above all, be realistic.
Examine what is said, not who speaks."But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail "Time is a poor substitute for thought"--theorbtwo "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon