Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!kksys!wd0gol!newave!john From: john@newave.UUCP (John A. Weeks III) Newsgroups: comp.software-eng Subject: Re: Code Inspections Message-ID: <644@newave.UUCP> Date: 9 Feb 91 01:28:21 GMT References: <15469.9102041851@olympus.cs.hull.ac.uk> <1991Feb6.143922.20539@cs.uiuc.edu> Reply-To: john@newave.mn.org (John A. Weeks III) Organization: NeWave Communications Ltd, Eden Prairie, MN Lines: 26 In article <1991Feb6.143922.20539@cs.uiuc.edu> marick@cs.uiuc.edu (Brian Marick) writes: > 2. I've found that writing the user's manual also tends to flush out > errors in a specification. I think this is because it makes you > approach the specification from a different perspective -- a good > user's manual explains the "why" of the specification. > Sometimes, you discover that the "why" doesn't make sense. I have noticed this when writing documentation for my programs. My rule of thumb is if I have to explain something, I must have approached the problem wrong. I have come across features that sounded so hokey when I wrote the manual that I had to go back and "fix" the program. BTW, most of these cases occured when I was trying to commercialize utility programs that just "grew", ie, programs that had features added as they were needed rather than programs that were developed from a spec. -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!tcnet!wd0gol!newave!john ===============================================================================