Re: Keeping up w/ design

[Glen Accardo <glen -at- SOFTINT -dot- COM>]

>    The problem I'm wrestling with: the system is still in development,
> and features change as fast as I can keep up with them.  It is not
> evolving toward a specific final form.  How have you dealt with
> situations like this?


I've been in, and am still in, that situation.  Here is the simple
(simple minded?) advice I have for you:

1.  Never make a promise.
    You can't write instructions for something that isn't designed yet.
    If they aren't done thinking about it/mucking with it, neither are
    you.  Try giving estimates as "Once you've brought the system into
    a stable, finished state, then I can estimate the writing/time
    involved."  Note that "stable, finished" does't mean perfectly
    final, but close enough for screen captures.

2.  Only work on stuff that's done.
    Besides involving yourself in fewer rewrites, you also get to wait
    until other stuff gets done.

3.  Talk to everybody everyday.
    This is the best way to find out when "done" is really gonna happen.
    Besides, it's a good practice to keep up with the rest of development.

4.  Learn to develop things "bottom up."
    Most people like to start with the big picture, make an outline, then
    fill in the details.  Try starting with the known details, and piecing
    them together as best you can.  This takes a bit of publishing wizardry,
    to rearrange text super-quick, but at least you are making use of the
    time and information currently available and working towards a
    complete manual.  Note, this is easier to do when you'll deliver the
    information online as opposed to print.

------------
glen accardo                         glen -at- softint -dot- com
Software Interfaces, Inc.            (713) 492-0707 x122
Houston, TX 77084

Did the Corinthians ever write back?