home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / software / 4236 < prev    next >
Encoding:
Text File  |  1992-11-11  |  10.2 KB  |  335 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!convex!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!cs.ubc.ca!news.UVic.CA!news.uvic.ca!mberkley
  3. From: mberkley@visions.uvic.ca (Mike  Berkley)
  4. Subject: REVISITING THE MYTHICAL MAN-MONTH
  5. Message-ID: <MBERKLEY.92Nov11121407@visions.uvic.ca>
  6. Summary: This is a short (5 question) software engineering course survey.
  7. Lines: 320
  8. Sender: news@sol.UVic.CA
  9. Nntp-Posting-Host: visions.uvic.ca
  10. Reply-To: mberkley@sirius.uvic.ca (J. Michael Berkley)
  11. Organization: University of Victoria
  12. Distribution: comp
  13. Date: 11 Nov 92 12:14:07
  14.  
  15. (This survey is being posted for a friend without Usenet access.)
  16.  
  17. Please give this survey the widest possible distribution.  The survey has
  18. only five questions.  I am especially interested in the comments of people
  19. who have experience designing and building large software projects.
  20.  
  21.  
  22.                 ****************************************
  23.                 *                                      *
  24.                 *   REVISITING THE MYTHICAL MAN-MONTH  *
  25.                 *                                      *
  26.                 ****************************************
  27.  
  28. ****************
  29. * INTRODUCTION *
  30. ****************
  31.  
  32. It has been seventeen years since Fredrick P. Brooks, Jr. published THE 
  33. MYTHICAL MAN-MONTH, a seminal book of essays on Software Engineering.  His 
  34. very readable book contains many insights into the discipline, and is still
  35. widely quoted.
  36.  
  37. Although much of what he wrote is current, some of his ideas are not reflected 
  38. in recent literature.  I am considering which of his ideas are still    
  39. current, and how Software Engineering has evolved from his insights.  I 
  40. would appreciate it if you could assist me by taking the time to answer the 
  41. following questions.  Feel free to say as much as you like, or give yes/no 
  42. answers.    
  43.  
  44. ALL OF THE QUESTIONS IN THIS SURVEY DEAL WITH LARGE SOFTWARE PROJECTS.
  45.  
  46. All responses will be kept confidential.  Please send your responses to: 
  47.  
  48. savage@cmr.ca 
  49.  
  50. I would appreciate receiving your response by November 21st, but any
  51. submission received by November 28th will be useful.
  52.  
  53. This research is part of a project for a graduate course in Software
  54. Engineering.  Please indicate any bulletin board you would like the final
  55. report posted to, or send me your E-Mail address if you would like a personal 
  56. copy.  I will get it to you by 16 Dec 92.
  57.  
  58. **************
  59. * THE SURVEY *              
  60. **************
  61.  
  62. Please answer as many or as few of the following biographical questions as
  63. you wish too.  Responses of "negligible", "basic", or "extensive" will be
  64. sufficient.
  65.  
  66. My formal training in Software Engineering is .....
  67.  
  68.  
  69. My experience in writing software specification is .....
  70.  
  71.  
  72. My experience is software design is ....
  73.  
  74.  
  75. My experience in programming is ....
  76.  
  77.  
  78. My experience in debugging software is ....
  79.  
  80.  
  81. My experience in maintaining software is ....
  82.  
  83.  
  84. My experience in managing software projects is ....
  85.  
  86.  
  87. I have .... years experienceh working on large software projects. 
  88.  
  89. My present role in software development is ....
  90.  
  91.  
  92.  
  93. * Background to question 1.  CONCEPTUAL INTEGRITY 
  94. Brooks contends that conceptual integrity is the most important consideration
  95. when designing a large software product.  He says that design must proceed 
  96. from one mind, or from a very small number of agreeing resonant minds.
  97. Brooks says that conceptual integrity is critical because it reduces the cost 
  98. of communication in designing a software product, reduces the number of bugs 
  99. designed into the system, and results in a system that goes together faster.  
  100. Brooks dedicates the first half of his book to exploring why conceptual 
  101. integrity is difficult to achieve, and methods for achieving it.  He asserts
  102. that the most pernicious and subtle bugs are system bugs arising from
  103. mismatched assumptions made by the authors of various components. 
  104.   Yet the need for conceptual integrity is one of the least quoted of 
  105. Brooks's ideas.  Maybe conceptual integrity was never that important, or  
  106. maybe more modern design techniques make conceptual integrity easier to 
  107. achieve amongst larger design teams.  Perhaps the need for conceptual
  108. integrity is such an obvious and basic requirement that it seldom needs 
  109. mentioning, or it might be that we still need to learn the most important 
  110. lesson that Brooks has to teach us.
  111.  
  112. THE MOST IMPORTANT QUESTION
  113. ***************************
  114.  
  115. Question 1.  Is conceptual integrity the most important consideration when
  116. designing a large software product.  If it is, why isn't the need for 
  117. it mentioned more often in Software Engineering literature?
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138. * Background to question 2.  COMMUNICATIONS WITHIN A SOFTWARE TEAM
  139. Brooks says "Communication and its consequent, organization, are critical
  140. for success.  The techniques of communication and organization demand from
  141. the manager as much thought and as much experience as the software technology
  142. itself."  Some of the communication techniques that he suggests are:
  143.         - weekly conferences of designers, programmers, and market planners
  144.           to discuss problems;
  145.         - semi-annual "supreme court sessions" to clear backlogs of 
  146.           open issues; 
  147.         - a formalized way of letting everyone involved in a project know
  148.           about minor decissions made informally, such as the response to a
  149.           question asked during a telephone conversation; and
  150.  
  151.   These are to avoid the "schedule disasters, functional misfits, and system
  152. bugs (that) arise because the left hand doesn't know what the right hand
  153. is doing."  With reguard to software specifications, the author states that
  154. natural language and formal notations are equally good for writing software
  155. specifications, provided that if both are used then it is clearly stated
  156. which is the primary specification.
  157.  
  158. Question 2.  Do you agree with Brooks's statements about communications.
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179. * Background to question 3.  SCHEDULING AND MANAGEMENT
  180. The chapters from THE MYTHICAL MAN-MONTH on scheduling and management contain
  181. many pearls of software engineering wisdom, such as:
  182.  
  183.         Disasters are usually due to termites, not tornadoes.
  184.  
  185. or the rhetorical question and answer
  186.  
  187.         How does a project get to be a year late?
  188.         ... One day at a time.
  189.  
  190. and Brooks's Law, which states
  191.  
  192.         Adding manpower to a late software project makes it later.
  193.  
  194. The author claims that more software projects have gone awry for lack of
  195. calendar time than for all other causes combined.  He gives five reasons for
  196. this common disaster, as he perceived the problem in 1975:
  197.         - techniques of estimating schedules were poorly developed, and
  198.           reflected unwarranted optimism about the number of bugs in the
  199.           code;
  200.         - estimating techniques confused effort with progress, hiding the
  201.           assumption that men and months are interchangeable;
  202.         - because we were uncertain of our estimates, software managers 
  203.           would bow to pressure to give optimistic completion dates;
  204.         - schedule progress was poorly monitored; and
  205.         - when slippage was recognized the natural response was to add
  206.           manpower, which Brooks describes as dousing a fire with gasoline.
  207. He also saw that most programming groups suffered from too little management
  208. rather than too much, and that schedule monitoring techniques proven and
  209. routine in other engineering disciplines were considered radical innovations
  210. in software engineering.
  211.  
  212. Question 3.  Has our ability to schedule and manage software projects 
  213. improved since 1975?
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234. * Background to question 4.  THE SURGICAL (CHIEF PROGRAMMING) TEAM
  235. An alternative model for organizing a programming team is the Chief 
  236. Programming Team (or Surgical Team) method.  Instead of dividing all tasks
  237. equally amongst all team members, tasks are specialized.  The team is lead
  238. by a chief programmer who is an experienced and highly qualified individual.
  239. He and his assitant write all of the code and documentation.  Other members
  240. of the team carry out specific functions such as librarian, toolsmith,
  241. tester, etc.  Brooks says that such an organization makes best use of your
  242. most experienced programmers, and aides conceptual integrity by reducing the
  243. number of minds that must be coordinated to build good software.
  244.  
  245. Question 4.  Is the Chief Programmer Team model used in practice?  If so, do 
  246. such teams work better then conventionally organized teams?
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267. * Background to question 5.  TESTING AND TOOLS
  268. Brooks places great importance on software tools and testing, both being  
  269. supported by dedicated resources.  He believes that it is inefficient for
  270. each programmer to have their own file of programming tools.  Rather, there
  271. should be a library of tools and a "toolsmith" to make any new tools that
  272. are required.
  273.   Brooks strongly advocates thorough testing of each software component
  274. before it is integrated with others.  He uses the term "scaffolding" to 
  275. describe software that is written specifically for testing, and says that
  276. it is reasonable for there to be half as much code for programs and data for
  277. debugging the system as there will be for the final product.  According to
  278. Brooks, fixing a defect has a 20 to 50% chance of introducing a new defect.
  279. Therefore, rigorous testing and quantizing changes during development are
  280. essential.  These practices will also result in a system that will fit
  281. together and be working sooner than one built with a "let's put it together
  282. and see if it works" approach.
  283.   Lastly, Brooks supports having an independant product testing team that
  284. serves as a devil's advocate, and checks the product against its
  285. specifications.
  286.  
  287. Question 5.  Do you agree with Brooks's statements about testing and tools?
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308. Question 6.  BONUS QUESTION
  309. Have you worked in a software organization that had a matrix-like
  310. organizational structure, rather than a tree-like one?  How well did it
  311. work?
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322. **************
  323. * CONCLUSION *
  324. **************
  325.  
  326. Thank you for completing this survey.  If you have not read THE MYTHICAL
  327. MAN-MONTH, I highly recommend it to you.  Most of its contents are still
  328. very pertinent, and it is enjoyable reading.
  329.  
  330. The Mythical Man-Month - Essays on Software Engineering
  331. Fredrick P. Brooks, Jr.
  332. Addison-Wesley Publishing Company; 1975, 1982
  333. ISBN 0-201-00650-2
  334.         BB-AL-89
  335.