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. Too Hard From Ruby vs. Java Myth #3:
In what serious discipline is "It's too hard" a legitimate excuse? 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."
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 Ruby vs. Java Myth #1, on big and small projects. This is a case where conventional wisdom gets things backwards, at a great cost to many teams. A Programmer's Programmer I recently ran across a link to this interview with Don Knuth from last year. It's worth a read. You gotta love Knuth as much as you respect his work:
In retirement, he still writes several programs a week.
Programmers love to program and just have to do it. But even with 40+ years of experience, Knuth admits a weakness:
"If I had been good at making estimates of how long something was going to take, I never would have started."
If you've studied AI or search algorithms, you from 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. -----