My 2-cents: Document at a high level. Example using UML Document your class interactions ( Maybe only a few public method/properties ) and subclassing structures. Document the important Use Cases via the Use Case Diagram ( Stick people, Ovals and arrows. ) Finally if data centric an ERD and Use an autodocumentor for any database tables. IMO the pay back for this for even for a 1 person shoop is many, many times the effort
Automatic testing e.g. foxUnit, Nunit etc. For middle tier work worth it weight in gold! -----Original Message----- >From: Hal Kaplan <[EMAIL PROTECTED]> >Sent: Sep 28, 2006 1:27 PM >To: ProFox Email List <profox@leafe.com> >Subject: RE: Agle Programming > >Most documentation is a waste of time and money. It is expensive to >produce. It is frequently not maintained, rendering it useless. And it >makes two very "iffy" assumptions: one that the author knows how to >write and two that the reader has a basis for comprehension. > >Heresy? Perhaps. > >My response to documentation (or lack of it) is that if I am going to >fix your code or expand it or whatever, I had better be smart enough to >understand what is there. If I cannot do that from looking at the >source code and perhaps a few test cases, then I should not be messing >with the stuff. Would you want to be under the care of a medical doctor >who had to rely on his class notes? > >Agile programming? It's an oxymoron. If one ordinary woman can give >birth to a child in nine months, nine agile women should be able to do >it in one month. > >HALinNY > > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
