home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 17061 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  4.3 KB
  1. Xref: sparky comp.lang.c:17061 comp.software-eng:4476
  2. Newsgroups: comp.lang.c,comp.software-eng
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!rjf
  4. From: rjf@dptg.att.com (51351[efw]-Robert Feddeler(MT4799)T343)
  5. Subject: Re: Why are some programmers more productive?
  6. Message-ID: <1992Nov23.212246.23522@dptg.att.com>
  7. Organization: AT&T/NCR, Lincroft, NJ, USA
  8. References: <1992Nov11.055130@eklektix.com> <BxMuBK.ArM@inews.Intel.COM> <1992Nov23.013343.23809@gmuvax2.gmu.edu>
  9. Distribution: usa
  10. Date: Mon, 23 Nov 1992 21:22:46 GMT
  11. Lines: 85
  12.  
  13.  
  14. [ I'm not sure this belongs in c.l.c, but that's where I found it. ]
  15.  
  16.  
  17. In article <1992Nov23.013343.23809@gmuvax2.gmu.edu> ofut@gmuvax2.gmu.edu (A. Jeff Offutt) writes:
  18. >This is a software engineering team project course -- they go through
  19. >the whole process, from requirements to integration.  A kid who thought
  20. >he was a very good programmer (he'd done very well in previous classes)
  21. >came up with a design for his team's subsystem that, while very clever,
  22. >was very inefficient.  During the design review, they pointed out that
  23. >they were halfway through coding -- had already written 1000 lines of
  24. >code.  But I pointed out a severe flaw, and a way to reduce the size of
  25. >the subsystem coonsiderably.  This did not make them happy, until I
  26.                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  27.  
  28.     ||  The truth angers those that it fails to convince.  ||
  29.  
  30.  
  31. >pointed out that they were now planning on writing about 1000 more
  32. >lines of code, and the new design would only require a couple of
  33. >hundred, so the new design was _still_ a net savings.
  34. >
  35.  
  36.  
  37. Yes, indeed!  Feddeler's Rules:
  38.  
  39. 1. For any problem, there are 1000 solutions, 100 of them will work,
  40.    but only 10 are correct.
  41.  
  42. Don't stop as soon as you find one of the 100 that will work.  Go back
  43. and criticize it.  Pick a few things you don't like, that you're most
  44. nervous about, and try to modify the design (perhaps dramatically) to
  45. eliminate those "risks".  Iterate until you've found a _correct_ solution.
  46. Simplicity is, of course, the critical test.
  47.  
  48.  
  49. 2. If it's hard to do, you ain't doing it right.
  50.  
  51. If, once you get into the details, you find yourself working hard
  52. (for any definition of hard), go back to the design and fix _it_.
  53. (This can be great sport if someone else did the design.)  Correct
  54. designs are _always_ easy to implement.  The resulting code "looks
  55. just like the problem".  Don't try to bury a bad design in a bunch of
  56. unmaintainable code.  Meta-languages and tools libraries often help
  57. here too.
  58.  
  59.  
  60. 3. Anything worth doing is worth doing twice.
  61.  
  62. Don't be afraid to admit that you've learned something by doing the
  63. actual implementation.  Don't hesitate to go back and rip out major
  64. components and re-design/write them.  Don't fight with the silly
  65. error message macro that requires a sprintf() into a locally-defined
  66. buffer before each and every call.  Bite the bullet now instead of
  67. dodging it forever.  Without exception, this is _always_ the right
  68. thing to do.  (Yes, boss, even if it does slip the schedule.  If we
  69. don't do it now, we'll slip _every_ schedule from now on.  Which
  70. would you prefer?)  The pay-off in total life-cycle cost can be
  71. enormous.
  72.  
  73.  
  74. Given a set of programmers that, after a 3-day weekend, can all still
  75. remember where the semicolons go, the "order-of-magnitude" differences
  76. we will observe in individual productivities will be proportional
  77. to the extent to which they apply these three simple rules.  A natural
  78. inclination to apply these rules is what we commonly refer to as
  79. talent.
  80.  
  81. BTW, my favorite example of a violation of the Rules is the difference
  82. between the Intel 8080 and the Motorola 6800 instruction sets.  IMHO,
  83. only one of these is a member of the "correct solution" set.  Could
  84. it be that somebody stopped iterating a bit too soon?  Talk about
  85. enormous life-cycle impact!  Yes, I know there's some history
  86. to take into account, but that's part of what Rule 3 is about.
  87.  
  88. The other issue here is "when is it okay to start writing code?"  In
  89. the absence of alternatives, the programming language can be a useful
  90. "design notation" so long as you don't violate Rule 3 by "falling in
  91. love with the code".  Think of it as a Program Design Language that
  92. you _might_ compile some day.
  93.  
  94.  
  95.  
  96. bob.            | Heap big trouble in the land of plenty.
  97. Were these more than just my opinions, they would have cost a bit more.
  98.