On Mon, Nov 01, 2004 at 01:53:59PM -0800, Jared Rhine wrote:
> [Mark == [EMAIL PROTECTED] on Mon, 1 Nov 2004 15:45:34 +0000 (UTC)]
> 
>   Mark> So, what resources are recommended to consult to make great
>   Mark> estimates?  What habits to develop?
> 
> Estimate only what you know...

Thank you Jared for the thorough response. You've increased my
confidence about how we already handle the "big picture" of estimating
here. I understand that short term estimates can be tighter and long
term estimates need to be vague. I get that estimating what I know is
easier, and estimating the unknown is riskier.     

I think fall down in particular on the small scale estimating: 5 to 50
hour chunks.  I will recall how long a similar project took, but not 
sufficiently account for all the ways the new project is different. 

The pure "programming" parts I think I tend to do pretty well out, 
it's the "overhead" factors that I have more trouble with, and these 
vary. For example, a project thas accumulated code over the last 5 years 
is going to have more overhead a new build-from-scratch system. :) 
But how much? 

My idea now is to better document how estimates pan out, instead of
relying on memory of past projects so much. I'm thinking of a simple
spreadsheet that would contain "budget" "actual" and "risk factors
factors"-- things that made the task tricky to estimate well. 

As time passes, I ought to see more patterns not just in the numbers,
but also in the risk factors. When I have a project that has similiar
risk factors, I would expect the overhead would be similar to an older 
project with similar factors.

I'm looking for detailed tips. For example, how you budget for automated
testing? In my experience, for small projects that launch and don't get 
much refinement, automated testing adds a little time. For larger more
complex projects, I would say automated testing saves time, because it
catches regressions, builds confidence to make changes, and speeds up a
lot of boring re-testing. 

In part, I haven't been using automated testing as long as I've been
programming, so I simply don't have as much experience to pull from when
estimating it as a factor. 

        Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   [EMAIL PROTECTED]     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

Reply via email to