Does this sound familliar to anyone?
Regardless of the fact that you have been programming in Access for umpteen
years, you still are overly optimistic when it comes to estimating time.
The client gives you a requirement that is "obviously just another form", and
your brain does a quick calculation, saying that should take 1 to 2 hours.
You know you tend to be optimistic, so you double the average of that, and
call it 3 hours.
Now, you actually start working on the form, and find out that the form worn't
work because there's been a problem with the schema - something neither you or
the client fully understood before, but having to implement this form has
brought into sharp relief. It's a minor issue, though, so you press on, add a
field, and keep going. You hit a few more unanticipated issues, a combo box
that needs an exceptional case, so add a table with a single-row, so you can
include it in queries with special case UNIONS, build a UNION query, etc...
Now, you're only 2 hours past your estimate - not too bad. You been
programming long enough, though, that you realize you need to spot check all
code in the app that's remotely related, because even though your changes
shouldn't affect anything else, you never know 'til you check. In testing,
you find a form that worked before, and now gives an error because you added
the field where it made sense in the field order, not at the end of the list
and Josephine who worked on the app before you used a query of that table with
<tablename>.* in the select list as a combo box source which now shows the
wrong field.
Damn, you say, fix it, then realize you'd better make sure there are no more
of those, so you fire up Speed Ferret, and search the project for tblFoo.*.
You find one more of those, and fix it. Now, you're 4 hours past the
estimate, and you were going to leave for the day. The boss is still there,
though, and everything looks fine, so you demo it for the boss.
The first thing the boss does is try something you didn't do in your tests,
you didn't know she ever did, and boom, it crashes. It seems you called a
procedure you've used successfully before to resize the subform if the user
resizes the main form, but it assumes the window will open at a size at least
as big as the detail section, and the boss had maximized a window before
opening the new one, and also had the Access application window non-maximized
such that the form opened at a size smaller than the detail section...
The above scenario is fictional, but contains elements similar to what I've
often seen in real life. How do other people here make their estimates as
accurate as possible given that the unexpected will occur more often than not
in spite of our best efforts? How do you make sure that you remember to track
how your progress is relating to your estimate early enough to let the client
know the estimate is wrong and why early enough to allow them to adjust
development priorities and delivery time expectations?
Some tricks I've found:
- Break tasks up into smaller pieces - no, smaller than that <g>. If a small
piece goes over time, it's not as big a deal, and the progress rate of the
smaller tasks acts as a gauge of how real time is comparing to estimated time
on the larger tasks that contain them.
- Use some cleverness to try to make each small task something that actually
delivers a useful piece of functionality to the user, so the user can cut
functional requirements or change the spec. on remaining functionality to
balance schedule vs completeness at any time.
- When something you do that shouldn't affect anything else does affect
something else, take extra time to fix the "something else" to be
better-behaved. Even though this adversely affects the schedule for the
current task, the time is made up with interest in very short order, keeping
your average delivery rate higher. This one is hard, because there is time
pressure on you now, but not doing it is throwing away good time after bad.
Think of this as part of every job, like cleaning up the kitchen after
cooking.
- Keep a historical log of planned vs actual, so you can see what kind of
unanticipated time costs tend to be incurred on what kinds of tasks. Refer to
past logs when estimating new tasks (Just starting this one - I'll post back
when I see how it goes).
