home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / programm / 3335 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.6 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!sgiblab!ultra!jerbil
  2. From: jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr})
  3. Newsgroups: comp.programming
  4. Subject: Re: collective program design
  5. Message-ID: <1992Dec18.214939.16716@ultra.com>
  6. Date: 18 Dec 92 21:49:39 GMT
  7. References: <fkaiser.724352429@Physik.TU-Muenchen.DE> <MAYERS.92Dec17114526@yak.syr.EDU>
  8. Organization: Ultra Network Technologies
  9. Lines: 99
  10.  
  11. As always, this is one man's opinion, based on my experiences.
  12.  
  13.  
  14. >> Frank Kaiser <fkaiser@Physik.TU-Muenchen.DE>
  15.  
  16.  
  17. >>The best public domain programs known were created by many programmers
  18. >>working together. Everyone of these did a little share of work. 
  19. >>But the begin and development of such a workgroup was a result of randomness. 
  20.  
  21.     Hmm, most of the freely-redistributable and public-domain programs
  22. I've seen began with a few people solving a problem.  Others laid additional
  23. code atop it, tweaked designs, and expanded the operating model along the
  24. same lines as the original operating model.  "Random" is very much the wrong 
  25. word to use here;  I think "informal" better captures the flavor.
  26.  
  27.     ("Random" implies that there is no intelligence or purpose behind
  28. an action;  "informal" implies that it wasn't necessarily done so that it
  29. could be done again.)
  30.  
  31.  
  32. >>One could think of rules for finding the need for a new program, for 
  33. >>example a newsgroup with suggestions for new programs, together with 
  34. >>a sort of democratic decision to start a new project. 
  35. >>For the development of such a project, one could thing of a bbs, where
  36. >>everyone willing to take a part of the burden can find a task to solve.
  37.  
  38.     We already have these. :-)  Someone complains about something,
  39. and he or someone else figures out a quick way to solve the problem.  Word
  40. (and software) leaks out, and pretty soon others are playing with it,
  41. making it more portable, more robust, and more usable.  Some of those changes
  42. make it back to the original author, and POOF the ball is rolling.
  43.  
  44.  
  45. >>This procedure should have to be higly formalized in a top-down-manner.
  46. >>I don't believe this is a new idea. Please comment it.
  47.  
  48.     Not sure what you mean by "top-down" in this context.  And no, it's
  49. not a new idea at all:  it's ad-hoc group software development.  However, you
  50. need motivated people to work on these projects, and continuity in the form
  51. of documentation and (often) regular social contact.
  52.  
  53.  
  54.  
  55.  
  56. >  Michael  Ayers <mayers@yak.syr.EDU>
  57.  
  58. >    The democratic process thing sounds like the weakest link - "Okay,
  59. > we've all agreed on what to do, now who's going to do it?" [silence]
  60.  
  61.     Wrong question, Michael.  "Okay, we've all agreed on what to do, now
  62. who's most interested in making sure the design stays intact?  Who's keeping
  63. track of what's happening?  And what do each of you want to start with?"
  64.  
  65.     A usual title for the person answering the first question is
  66. "principal architect" or "principal designer":  he is the final word on
  67. this group as a whole believes should be the content of the software.
  68. He also is the one to divide up the work, with the help of everyone else.
  69.  
  70.     A usual title for the second person is "project manager":  he is
  71. the final word on getting the resources and organization necessary for the
  72. project to progress.  He also is the one to track that the work continues,
  73. and takes care of the process.
  74.  
  75.     Depending on the group, the principal architect or the technical
  76. manager makes any assignments.  With smaller, ad-hoc groups where everyone
  77. works as peers and could do any task nearly as well as anyone else, the tasks
  78. go to those most interested in doing them.
  79.  
  80.  
  81.  
  82. >    I do agree that a newsgroup or mailing list for thinktanking
  83. > prospective projects would be a good idea, I just think that a relatively
  84. > anarchic framework is mandatory - project control must remain entirely
  85. > within the group which does the work.
  86.  
  87.     And someone within the group needs to handle the process, at least to
  88. the extent that everyone can build with everyone else's pieces.
  89.  
  90.  
  91.  
  92. >    I can see myself working on my own baby, and then giving it away. I
  93. > can picture myself working on someone else's project, so long as they were
  94. > nice to me, so they could give it away.  Working for a committee?  Sorry,
  95. > I just can't picture myself doing that for free.
  96.  
  97.     Ah, but working for (and with) a peer group is something else entirely.
  98. I infer that "committee" means a group which emphasizes process over content.
  99. Other climates for working within a group exist.  I for one think that this
  100. would be a neat and logical extension of GNU and other freely-redistributable
  101. work.
  102.  
  103.  
  104.         Joseph Beckenbach
  105.         toolsmith and releaser
  106. -- 
  107. ----
  108. Joseph Beckenbach    jerbil@ultra.com    408-922-0600 x246
  109.     (speaking from, but not for, Ultra Network Technologies)
  110.