Estimation

stephen has asked for the wisdom of the Perl Monks concerning the following question:

Okay, there's nothing Perl-specific about this question, but I'm interested in everyone's answers to it anyway.

Is there a good way of coming up with estimates of how long a programming project will take? I generally start with a module breakdown, then estimate the number of lines of code in each module, then based on that do a total guess on how many hours each module will take. I break stuff down as far as I can, hoping that the errors I make will cancel themselves out. Then I multiply the whole thing by 2, since I've got only a 50% chance of being right.

(Then I hit CPAN, grab whatever I can, and use the time I save doing that to try to hit my deadline.)

Granted, everyone uses a different method of coming up with estimates, and yours might not work for me. But is this the best way of doing time estimates for Perl projects? Are there better methods?

Comment on Estimation

Replies are listed 'Best First'.
RE: Estimation by Anonymous Monk on Apr 03, 2000 at 04:20 UTC
My father always said: "Ask ten developers to estimate how long it will take and then add their answers together :-)" On a more serious note I think you need to look at other factors 1) Risk a) Have I done this before? b) How well is the problem/solution specified - are all the factors understood? c) Is this novel in any way? New platform, new software, new interfaces 2) Have I allowed enough time for other things? a) Meetings/discussions b) Weekely progress reports - (even if you only write them to yourself they focus the mind on what you really got done!) c) Keeping the documenation up to date and manageing changes This is a BIG time sink!!!! d) email, admin and all the other things that only make you productive 40-60% of the time 3) Complexity. How many data connections and control flows are there netween my modules and between my system and other systems 4) How many thinks can go wrong 5) How many people are involved Alec alec.clews@merant.com	[reply]

Replies are listed 'Best First'.

RE: Estimation
by Anonymous Monk on Apr 03, 2000 at 04:20 UTC

My father always said: "Ask ten developers to estimate how long it will take and then add their answers together :-)" On a more serious note I think you need to look at other factors 1) Risk a) Have I done this before? b) How well is the problem/solution specified - are all the factors understood? c) Is this novel in any way? New platform, new software, new interfaces 2) Have I allowed enough time for other things? a) Meetings/discussions b) Weekely progress reports - (even if you only write them to yourself they focus the mind on what you really got done!) c) Keeping the documenation up to date and manageing changes This is a BIG time sink!!!! d) email, admin and all the other things that only make you productive 40-60% of the time 3) Complexity. How many data connections and control flows are there netween my modules and between my system and other systems 4) How many thinks can go wrong 5) How many people are involved Alec alec.clews@merant.com

[reply]