In defense of XP, they don't claim that you should NEVER do documentation; rather, they claim you should only do comments or documentation for the difficult or critical sections of the code.
Alas, they fail to give either a set of standards or a methodlogy for determine exactly what those sections are. Ruven Brooks -----Original Message----- From: Ron Burk [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 10:52 AM To: [EMAIL PROTECTED] Subject: RE: PPIG discuss: statistical study about commenting > How many other craft disciplines have secondary notations >of this kind? Interesting thought -- I can't think of any really good analogies. A related peripheral thought: view comments as work that (can) improve quality (maintainability, debuggability), but without immediate and tangible benefits. Then look for analogous psych studies on what factors affect whether people do such work. Hmm, or whether people creating the tangible product are even the best-equipped to inject secondary, less-tangible quality of this nature. Does Toyota really imbue each worker with the skills and motivation to constantly seek improved quality, or do most of their quality successes come from having key people whose focus is nothing but quality? And, if comments can be characterized as work without immediate and tangible benefits, are there similar aspects of programming that are correlated with a lack or plethora of comments? For example, are people who comment regularly more likely to make a separate pass over newly-constructed code to search for security flaws or opportunities to increase robustness or appropriate places to insert assertions? And, what is going on in the heads of programmers who enjoy commenting that is different than in the heads of programmers who do not? And, theory: part of the popularity of "agile" methodologies like XP is that they reduce cognitive dissonance for programmers who found such things as commenting unenjoyable (aha -- I see now that I was not a lazy commenter, but was actually practicing an advanced methodology that eschews all forms of documentation). How could one construct an experiment to test this theory? And, do programmers who dislike commenting feel that way because it disrupts flow? If commenting was introduced as a separate pass, with a separate set of feedback mechanisms, could it be turned into a flow experience for those programmers? (e.g., you do a separate pass for comments, then hand it to Joe; any questions he has to ask about how the code works represent additional requirements for the commenting). After fifty years, programmers can't even agree on whether we should be writing comments or not -- what fertile ground for psychological investigation! - Automatic footer for [EMAIL PROTECTED] ---------------------------------- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED] - Automatic footer for [EMAIL PROTECTED] ---------------------------------- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
