home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 5046 < prev    next >
Encoding:
Text File  |  1992-12-18  |  3.3 KB  |  75 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!travis
  3. From: travis@eecs.nwu.edu (Travis Marlatte)
  4. Subject: Re: Software Inspections.  How many does it take?
  5. Message-ID: <1992Dec17.231020.7917@eecs.nwu.edu>
  6. Organization: Rauland-Borg Corporation, Skokie IL
  7. References: <1992Dec14.192008.15480@gallant.apple.com>
  8. Date: Thu, 17 Dec 1992 23:10:20 GMT
  9. Lines: 64
  10.  
  11. In article <1992Dec14.192008.15480@gallant.apple.com> neumann.m@applelink.apple.com (mark neumann) writes:
  12. >But what about module level design/code
  13. >inspections, where the work being inspected is the result of one persons
  14. >effort?
  15.  
  16. This is probably where one needs a review the most. One person designing
  17. and coding a segment of code needs to have someone else check it out.
  18.  
  19. >It seems obvious that having someone check your work is a good idea.  It
  20. >also seems that each additional person that checks your work is less
  21. >likely to find a problem (on average).
  22.  
  23. This can be true if you invite people to a review just to fill in seating
  24. space in the conference room. If, on the other hand, you invite people
  25. who have expertise in specific areas, their collective perspective is
  26. much broader than any one of them.
  27. >
  28. >My question:  Is one person enough?  Does anybody else use a single
  29. >reviewer approach?
  30.  
  31. The approaches that one finds in the text books really deal with large
  32. software projects. If I am designing and coding a major subsystem of
  33. a large project, the interactions that my code will have with other parts
  34. of the system and the outside world require me to invite a large number
  35. of people to a review. Each one may have insight to a particular
  36. interaction that none of the others does.
  37.  
  38. If I am making a small change or coding a small section that is fairly
  39. confined in the system, I really only need to have one maybe two people
  40. take a look at it. I'll probably throw a copy on their desk and ask them
  41. to take a look at it.
  42.  
  43. >
  44. >I believe that there are interpersonal dynamics which make one reviewer
  45. >more effective than two of more.  With two or more people, the ego of the
  46. >person whose work is being reviewed is more likely to become a factor.
  47. >
  48. >Finally, by assigning a single reviewer to inspect someone elses work,
  49. >that person is obviously  responsible for any flaws that get through, so
  50. >he/she is likely to take the role seriously. (Note: you probably do not
  51. >want to assign people to inspect each other's work, since they may agree
  52. >to just trust each other completely).
  53.  
  54. This is a big issue with reviews. An organization must mature to the point
  55. where egos are not a problem. It only takes a couple of well run reviews
  56. to get people used to the idea.
  57.  
  58. Having the reviewers sign off on a review to make them responsible is
  59. good on paper but doesn't translate to anything in the real world.
  60.  
  61. In the end, when the bug gets reported, the person managing the code
  62. will be responsible no matter who coded or reviewed it. Reviewers should
  63. take the responsibility seriously with a desire to share their insight
  64. to improve software quality. Authors should take suggestions graciously
  65. with the same attitude.
  66.  
  67. Any discrepencies in attitude should be handled with philosophy not
  68. policy. Noone should attend a review they don't want to be at. It is
  69. a waste of time for him or her and counter-productive for everyone else.
  70.  
  71. -- 
  72. Travis Marlatte
  73. travis@eecs.nwu.edu
  74. 708-297-0055
  75.