home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 5032 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.9 KB  |  64 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end.matawan.nj.us
  4. Subject: Re: Software Inspections.  How many does it take?
  5. Message-ID: <1992Dec16.153125.28269@mole-end.matawan.nj.us>
  6. Summary: One way to do reviews
  7. Organization: :
  8. References: <1992Dec14.192008.15480@gallant.apple.com>
  9. Date: Wed, 16 Dec 1992 15:31:25 GMT
  10. Lines: 52
  11.  
  12. In article <1992Dec14.192008.15480@gallant.apple.com>, neumann.m@applelink.apple.com (mark neumann) writes:
  13. > Recently I have been reading Capers Jones new book "Applied Software
  14. > Measurement", McGraw Hill.  ...
  15.  
  16. > ...  However, the inspection technique he describes  requires a
  17. > bunch of people! ...
  18.  
  19. > All five (or more) may be present for large projects.  For small projects
  20. > dual roles can be assigned, so that the minimum number for a true
  21. > inspection is three: moderator, author, and one other person. "
  22.   ...
  23. > In my experience, when the schedule pressure is on, most of the attendees
  24. > at large formal code walkthroughs are too busy with their own work to
  25. > carefully go over the material being reviewed.  ...
  26.  
  27. > It seems obvious that having someone check your work is a good idea.  ...
  28.  
  29. > My question:  Is one person enough?  Does anybody else use a single
  30. > reviewer approach?
  31.  
  32. > I believe that there are interpersonal dynamics which make one reviewer
  33. > more effective than two of more.  With two or more people, the ego of the
  34. > person whose work is being reviewed is more likely to become a factor.
  35.  
  36. I think just the opposite.  With one person, any sense of resentment can
  37. more easily focus on the person.
  38.  
  39. I worked on a project that had a weekly change cycle.  The day before the
  40. changes went in, people gathered in groups of three and four to review
  41. each other's work.  Everyone would have a change to put in, everyone would
  42. look over the code that others would be putting into their joint work.
  43. Everyone could expect to have a problem found, but nobody was on the
  44. spot because everyone would have their chance to have their mistakes
  45. exposed.  And because we worked with each other every day, we were all
  46. the more careful when we had to say `this is just no good,' which will
  47. happen to the best of us from time to time.  On the other hand, nobody
  48. was embarrassed to ask `could we have a comment on that?' when there
  49. was something that we'd need to know when looking at the code again.
  50.  
  51. It took a couple of years to reach this stage, and not all the supervisory
  52. groups were there yet.  But I think it could have continued indefinitely
  53. and I know there were a number of bugs that were fixed before they went in.
  54.  
  55. And having everyone take their turn in one session kept it cooperative.
  56.  
  57. It seems to me that this would be an interesting topic for a psychologist.
  58. Any experts on group dynamics care to comment?
  59. -- 
  60.  (This man's opinions are his own.)
  61.  From mole-end                Mark Terribile
  62.  
  63.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  64.