TITLE: Miscellaneous Thoughts for Programmers
AUTHOR: Eugene Wallingford
DATE: June 05, 2007  8:11 AM
DESC: 
-----
BODY:
As summer begins for me, I get to think more about
programming.  For me, that will be Ruby and my compilers
over the next few months.

<EM>Too Hard</EM>

From
<A HREF="http://www.relevancellc.com/2007/6/4/ruby-vs-java-myth-3-ruby-is-too-hard">
   Ruby vs. Java Myth #3</A>:

<BLOCKQUOTE><EM>
<STRONG>In what serious discipline is "It's too hard" a legitimate
excuse?</STRONG>  I have never seen a bank that eschews multiplication:
"We use repeated addition here--multiplication was too hard for our
junior staffers."  And I would be uncomfortable if my surgeon said,
"I refuse to perform procedures developed in the last 10 years--it
is just too hard for me to learn new techniques."
</EM></BLOCKQUOTE>

Priceless.  This retort applies to many of our great high-level
languages, such as Scheme or Haskell, as anyone who has taught
these languages will attest.

The problem we in software have is this conundrum:  The level of
hardness -- usually, abstraction -- we find in some programming
languages narrows our target population much more than the level
of hardness that we find in multiplication.  At the same time,
our demand for software developers far outstrips our demand for
surgeons.  Finding ways to counteract these competing forces is
a major challenge for the software industry and for computing
programs.

For what it's worth, I strongly second Stuart's comments in
<A HREF="http://www.relevancellc.com/2007/6/2/ruby-vs-java-myth-1-project-size">
   Ruby vs. Java Myth #1</A>,
on big and small projects.  This is a case where conventional
wisdom gets things backwards, at a great cost to many teams.

<EM>A Programmer's Programmer</EM>

I recently ran across a link to this
<A HREF="http://www.stanfordalumni.org/news/magazine/2006/mayjun/features/knuth.html">
   interview with Don Knuth</A>
from last year.  It's worth a read.  You gotta love Knuth as
much as you respect his work:

<BLOCKQUOTE><EM>
In retirement, he still writes several programs a week.
</EM></BLOCKQUOTE>

Programmers
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-12.html#e2006-12-02T10_42_40.htm">
   love to program</A>
and just have to do it.  But even with 40+ years of experience,
Knuth admits a weakness:

<BLOCKQUOTE><EM>
"If I had been good at making estimates of how long something
was going to take, I never would have started."
</EM></BLOCKQUOTE>

If you've studied AI or search algorithms, you from
<A HREF="http://en.wikipedia.org/wiki/A*_search_algorithm">
   A*</A>
that underestimates are better than overestimates, for almost
exactly the reason that they helped Knuth.  There are
computational reasons this is true for A*, but with people it
is mostly a matter of psychology -- humans are more likely to
begin a big job if they start with a cocky underestimate.
"Sure, no problem!"

If you are an agile developer, Knuth's admission should help
you feel free not to be perfect with your estimates; even the
best programmers are often wrong.  But do stay agile and work
on small, frequent releases...  The agile approach requires
short-term estimates, which can be only so far off and which
allow you to learn about your current project more frequently.
I do not recommend underestimates as drastic as the ones Knuth
made on his typesetting project (which ballooned to ten years)
or his Art of Computing Programming series (at nearly forty
years and counting!)  A great one like Knuth may be creating
value all the long while, but I don't trust myself to be
correspondingly productive for my clients.
-----