From: rjf@dptg.att.com (51351[efw]-Robert Feddeler(MT4799)T343)
Subject: Re: Why are some programmers more productive?
Organization: AT&T/NCR, Lincroft, NJ, USA
Distribution: usa
Date: Mon, 23 Nov 1992 21:22:46 GMT


[ I'm not sure this belongs in c.l.c, but that's where I found it. ]


In article <1992Nov23.013343.23809@gmuvax2.gmu.edu> ofut@gmuvax2.gmu.edu (A. Jeff Offutt) writes:
>This is a software engineering team project course -- they go through
>the whole process, from requirements to integration.  A kid who thought
>he was a very good programmer (he'd done very well in previous classes)
>came up with a design for his team's subsystem that, while very clever,
>was very inefficient.  During the design review, they pointed out that
>they were halfway through coding -- had already written 1000 lines of
>code.  But I pointed out a severe flaw, and a way to reduce the size of
>the subsystem coonsiderably.  This did not make them happy, until I
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

	||  The truth angers those that it fails to convince.  ||


>pointed out that they were now planning on writing about 1000 more
>lines of code, and the new design would only require a couple of
>hundred, so the new design was _still_ a net savings.
>


Yes, indeed!  Feddeler's Rules:

1. For any problem, there are 1000 solutions, 100 of them will work,
   but only 10 are correct.

Don't stop as soon as you find one of the 100 that will work.  Go back
and criticize it.  Pick a few things you don't like, that you're most
nervous about, and try to modify the design (perhaps dramatically) to
eliminate those "risks".  Iterate until you've found a _correct_ solution.
Simplicity is, of course, the critical test.


2. If it's hard to do, you ain't doing it right.

If, once you get into the details, you find yourself working hard
(for any definition of hard), go back to the design and fix _it_.
(This can be great sport if someone else did the design.)  Correct
designs are _always_ easy to implement.  The resulting code "looks
just like the problem".  Don't try to bury a bad design in a bunch of
unmaintainable code.  Meta-languages and tools libraries often help
here too.


3. Anything worth doing is worth doing twice.

Don't be afraid to admit that you've learned something by doing the
actual implementation.  Don't hesitate to go back and rip out major
components and re-design/write them.  Don't fight with the silly
error message macro that requires a sprintf() into a locally-defined
buffer before each and every call.  Bite the bullet now instead of
dodging it forever.  Without exception, this is _always_ the right
thing to do.  (Yes, boss, even if it does slip the schedule.  If we
don't do it now, we'll slip _every_ schedule from now on.  Which
would you prefer?)  The pay-off in total life-cycle cost can be
enormous.


Given a set of programmers that, after a 3-day weekend, can all still
remember where the semicolons go, the "order-of-magnitude" differences
we will observe in individual productivities will be proportional
to the extent to which they apply these three simple rules.  A natural
inclination to apply these rules is what we commonly refer to as
talent.

BTW, my favorite example of a violation of the Rules is the difference
between the Intel 8080 and the Motorola 6800 instruction sets.  IMHO,
only one of these is a member of the "correct solution" set.  Could
it be that somebody stopped iterating a bit too soon?  Talk about
enormous life-cycle impact!  Yes, I know there's some history
to take into account, but that's part of what Rule 3 is about.

The other issue here is "when is it okay to start writing code?"  In
the absence of alternatives, the programming language can be a useful
"design notation" so long as you don't violate Rule 3 by "falling in
love with the code".  Think of it as a Program Design Language that
you _might_ compile some day.



bob.			| Heap big trouble in the land of plenty.
Were these more than just my opinions, they would have cost a bit more.