Re: Developer docs on existing code and systems

["Anthony Markatos" <tonymar -at- hotmail -dot- com>]

Salan asked how to document database [schemes], code, etc. after the product 
has already been created.  He states that a primary reason for doing such is 
to bring new developers quickly up-to-speed.

Tony Markatos resonds:

Creating data flow diagrams and entity relationship diagrams (or their 
object-oriented equivalents) and other system documentation is accomplished 
in the same manor for existing systems as for yet-designed systems.  When 
documenting exising systems, you may do little (if any) end user 
interviewing - and a lot more developer interviewing; however, the same 
techniques apply.  There are no seperate after-the-fact techniques.

Be aware of what is probably happening here: The developers were supposed to 
have created such documentation.  They need to do such to ensure that their 
design is efficient and effective.  The fact that the creation of such 
documentation has been delayed until now means that this documentation is 
going to be much more complex: ad-hoc design always results in overly 
complex software - often hoplessly overcomplex software.  (I have 
experienced more than one situation where trying to document software 
after-the-fact is like trying to document the wind.)

CAUTION: If you are the first person to perform a disciplined systematic 
analysis of the product, what out!  You will find all kinds of inefficiences 
(and plain-old errors).  The designers may not appreciate these being 
brought to their attention late in the cycle.

Tony Markatos
(tonymar -at- hotmail -dot- com)

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com