home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16604 < prev    next >
Encoding:
Text File  |  1992-11-16  |  6.4 KB  |  147 lines
  1. Path: sparky!uunet!mcsun!julienas!corton!ircam!francis
  2. From: francis@ircam.fr (Joseph Francis)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Productivity of a C programmer ? (Close, but no tomato)
  5. Message-ID: <1992Nov16.171733.12948@ircam.fr>
  6. Date: 16 Nov 92 17:17:33 GMT
  7. References: <721104893@sheol.UUCP> <572@ulogic.UUCP> <1992Nov12.230327.8660@eecs.nwu.edu>
  8. Organization: IRCAM, Paris (France)
  9. Lines: 136
  10.  
  11. In article <1992Nov12.230327.8660@eecs.nwu.edu> travis@eecs.nwu.edu (Travis Marlatte) writes:
  12. >I don't understand the need to look at the source code to establish
  13. >productivity. Actually, I don't understand the need to establish
  14. >productivity at all. It definitely isn't needed to quote future
  15. >projects.
  16.  
  17. Of course it is. One can write anything, and people on the net
  18. frequently do write anything, or what might better be termed "nothing,
  19. nothing at all".  But to impart meaning is to have a personality which
  20. people regard.  Writing 'need to look at source code [...] isn't
  21. needed to quote future projects' doesn't lend credibility to yourself.
  22. Source code quality should be considered intimately with future
  23. project scheduling considerations. There is a reason for the phrase
  24. "quick and dirty".
  25.  
  26. >For example, when a hardware engineer creates estimates for a new
  27. >circuit he doesn't say, "I figure its going to have 1500 resistors,
  28. >1000 capacitors, 150 ICs... therefore based on ohms per hour I should
  29. >have this done in 14.6 man-days."
  30.  
  31. Unless the EE is dealing with VLSI design, perhaps, though you
  32. exaggerate, as could I. Design considerations should, however, flow
  33. from functional element identification - leading in a way to estimates
  34. based on nuts and bolts. If one doesn't design software (I write of
  35. projects) based on sufficient/necessary criteria for final perforance,
  36. and therefore elements to fulfill those criteria (down to details),
  37. then what is is based on? (as follows, I suppose)
  38.  
  39. >And when the circuit is complete, other engineers don't evaluate it based
  40. >on the number of compontents. They may evaluate its complexity, but not
  41. >directly its component count. Imagine a manager saying, "We're giving you
  42. >a raise. You deserve it. Last year you completed designs with 1M components.
  43. >Congratulations!"
  44.  
  45. I would suspect the raise would be inversely proportional to the
  46. number of components used, among other factors. In complex systems,
  47. the higher a component count, the more difficult it can be to debug
  48. (except for well-black-boxed systems) and the smaller MTBF. A toy
  49. example: would be the management of hundreds of variables external to a
  50. program functional block is quite different than the management of a
  51. few, and the sheer number of such pieces in a large system induces a
  52. sort of glazed-eye conscious overlooking of their impact.
  53.  
  54. >When a programmer asks me to evaluate his work, I am not immediately
  55. >interested in the source code. I want to first know
  56.  
  57. >    - how cleanly does it interact with the other parts of the system.
  58.  
  59. Divined, I suppose, by looking at tea leaves left after the
  60. Chinese-delivery food all-night frantic coding session breaks.
  61.  
  62. >    - how well it interacts with the user (if any)
  63.  
  64. The most important part of any network system, in my mind. And
  65. clearly the most quantifiable, in the overall scheme of things.
  66.  
  67. >    - how does its processing time compare with ideal
  68.  
  69. Since we know all software is frequently used until the end of time
  70. the total processing time is much more important than the time that
  71. will be used to adapt and modify the source by others. Also, clearly
  72. quantifiable, since the ideal system is completely characterized.
  73.  
  74. >    - how does its elapsed processing time fit into the system
  75.  
  76. Ditto.
  77.  
  78. >    - how much executable space does it consume
  79.  
  80. Though I hear with PDP-11/70s under RSX there are shareable libraries.
  81.  
  82. >    - how much memory does it require worst case
  83.  
  84. Those nasty 64k boundaries.
  85.  
  86. >    - what trade-offs were made for code space against time
  87.  
  88. Why, we made all variables global so we wouldn't have to push them
  89. onto stack to make function calls.
  90.  
  91. >These are the external characteristics that can be quantified and compared.
  92. >I can compare the results of multiple programmers based on this kind
  93. >of information.
  94.  
  95. Rather than clarity of code; the ability of other programmers to
  96. support their code (since we know that programmers are lifetime
  97. members of design teams); efficiency; cleanliness of code-interface.
  98. Layering. Orthogonality. Completeness.  Regression-testability.
  99. Portability. And those last fabulous catchwords "Extensibility" and
  100. "Scaleability".
  101.  
  102. >Then I want to look at the code. If it runs close to ideal in a minimal
  103. >amount of code space but the source code is unintelligible, it's garbage
  104. >unless there is a real need for the resulting performance. But if the
  105. >need is there, then speghetti code can be justified (sometimes).
  106.  
  107. Yes, most major programming projects I've worked on, when poorly
  108. designed, hired the Q/D (quick and dirty) consulting department and
  109. fired nasty old Q/A. Bad code has a way of living forever, in a manner
  110. akin to 'beating a dead horse', while good code is immortalized,
  111. adapted, cloned, propagated.
  112.  
  113. >If a programmer cannot provide the above information, then I don't think
  114. >the programmer actually engineered the code. It is more a result of hacking
  115. >together the first idea that had a chance - maybe with improvements done
  116. >after it was once working.
  117. >
  118. >Lines of code and comments only add to readability. They mean nothing
  119. >in terms of productivity. I can take 6 months to engineer an algorithm
  120. >and make it readable in a day.
  121.  
  122. You left out the smileys. Code like this ends up like T.S. Eliot's
  123. explanation of the meaning of "The Wasteland" - when he wrote it, he
  124. and God knew of its deeper meanings. Now only god knows.
  125.  
  126. People like this should be forced to work without manuals.
  127.  
  128. >Why are you all so interested in productivity? If your jobs depend on it,
  129. >then maybe you should find a company that is more interested in real results
  130. >rather than fluff. Can you say 90210? I thought you could.
  131.  
  132. Its just that not many companies are interested in genii who routinely
  133. use xor's to swap two variables 'cause its faster, and uses less
  134. processor time, and makes for smaller executables, and has much better
  135. worst-case memory requirements, and is lots faster in code-space than
  136. the time-space continuum.
  137.  
  138. Real results are finished useful projects.
  139.  
  140. Vaporware is the result of cool demos sublimating in the light of day.
  141.  
  142.  
  143.  
  144. -- 
  145. | Le Jojo: Fresh 'n' Clean, speaking out to the way you want to live
  146. | today; American - All American; doing, a bit so, and even more so.
  147.