> 1. Do I spend most of my time coding intuitively,
> then document my resulting work later? And,
> consequently, docs always lags ... Why wait for the
> docs to be ready to release the software?
> 2. Or do I design everything on paper beforehand
> and maintain this documentation during my
development
> work?
> Alain: I know the second choice is the textbook
> answer to this dilemna but, in real life, it is more
> often the first tactic that is used instead, eh!
> (myself included)
Anthony: I'd say the first tactic is better. Far
better.
Alain: In practice, I agree with you Anthony. It's
what I have always done, in fact, because I always
worked alone and also because my customers were very
easy-going about these formalities (because they were
paying a mere fraction of what it's worth). But the
larger projects are now requiring me to rethink my
haphazard methodology (habits). Larger systems are
inherently more complex, they often require the
collaboration of several people, and thus they require
more planning and coordination, which in turn requires
some kind of reference that everyone in the project
can be guided by (e.g. docs ).
Anthony: I find it silly to write TFM before there is
software to write it about -- you'll just end up
re-writing the manual anyway.
Alain: A lot of details do indeed change during the
development, testing and revision phases of a project,
but they should be in large part implementation
DETAILS. The overall architecture and functionality of
the system (that the docs establish) should not be
dramatically affected by them.
Anthony: But, even better is the side-to-side method.
Alain: An approach that combines Bottom-Up with
Top-Down is probably the best pragmatic strategy (for
now), in ComputerSci as well as in Educational design.
Alain: The Top-Down approach has always received the
Lion's share of developers attention, so we should
probably concentrate on the MUCH-less popular
Bottom-Up development strategy (equity). Besides,
given our present difficulties at arriving at a
consensus on features (on anything in fact), it seems
natural to use a Bottom-Up approach. Everyone builds
the individual parts that he wishes, and we weave all
these disparate parts together later on. If this
sounds risky, then you understand why the developers
of the Top-Down approach nearly always prevail. In
fact, they often have no other alternative because the
people that finance projects are an insecure lot that
insist on forecasting the outcome before they invest
their precious capital. But, since we are not looking
to be financed, we have the luxury of choosing the
Bottom-Up or a combination of the two. On a final
note, I would like to point out that my studies in
Artificial Intelligence and Communication have
persuaded me that the Bottom-Up approach to AI (e.g.
A-Life) is the most promising one for achieving this
lofty goal.
Anthony: Think Differently <g>.
Alain: Evolving artificially-alive intelligent
learning agents ... How's that for thinking differently?
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
