Actually, when I was working with Chuck he usually wrote it three times:
 1. "It can't possibly be that complicated."  Very simplistic model that
 captures the essence of the problem but ignores a lot of the requirements.

 2. "But you have to handle these other situations..." Complications get
 added to handle more and more of the requirements, encrusted on the original
 base.

 3. "Ah, now I see what we need."  Starting over from scratch, he can now
 build a clean implementation that accomodates all the requirements from the
 ground up.

 Unfortunately, many projects end up with an extended Stage 2, and never
 progress to Stage 3.  Chuch always had the courage to grasp when it became
 necessary to abandon Stage 2 and start over, even though it often caused
 consternation for the customer!

 Mike wrote:
 > What is a smaller lisp implementation that runs on both
 > gnu/linux and windows?

 Let's see, the user will have to install Linux to run the program, but
 the footprint of that program has to be small. :)

 Have you run a system call trace lately on, oh, the ``ls'' program?
 Tons of shared libraries attached. System calls flying left and right.
 A bazillion nonexisten files searched after.

 Linux is not exactly small and lightweight (any  more).

 Here is a comparison between a directory listing and evaluating a
 single expression with CLISP:

 machine:$ strace clisp -norc -q -x '(+ 2 2)' 2>&1 | wc
    260    1963   19729
    machine:$ strace ls /dev/null 2>&1 | wc
        111     870    8225

 It only takes about 2.5 times as many system calls to start up CLISP to
 evaluate an expression than to fetch a directory listing for a single
 file.

 The size of this Lisp system is less than 3 megabytes: a 1.2 meg
 executable and a memory image that is about 1.4 megs.

 Then we add up the shared libraries:
 machine:$ ldd ~/lib/clisp/base/lisp.run | gawk '{ print $3 }' | xargs
 du --total --dereference
 176     /usr/lib/libreadline.so.4
 852     /usr/lib/libncurses.so.5
 16      /lib/libdl.so.2
 1540    /lib/tls/libc.so.6
 20      /usr/lib/libgpm.so.1
 112     /lib/ld-linux.so.2
 2716    total

 The shared libs are as big as the program.  The kernel on this system
 (the uncompresed vmlinux file, not the compressed vmlinuz!) is about
 3.5 megabytes, whoa! Of course, all these executable images have
 run-time storage requirements as well.

 This particular Lisp system is smaller than the kernel, smaller than
 the total size of the shared libraries attached to it, and cranks out
 only about 2.5 as many system calls to evaluate an expression and quit
 as ``ls /dev/null''.

widgets.precisionis.com.au/

More than a century of studies show that long-term useful worker output is maximized near a five-day, 40-hour workweek. Productivity drops immediately upon starting overtime and continues to drop until, at approximately eight 60-hour weeks, the total work done is the same as what would have been done in eight 40-hour weeks.

In the short term, working over 21 hours continuously is equivalent to being legally drunk. Longer periods of continuous work drastically reduce cognitive function and increase the chance of catastrophic error. In both the short- and long-term, reducing sleep hours as little as one hour nightly can result in a severe decrease in cognitive ability, sometimes without workers perceiving the decrease.

www.igda.org/articles/erobinson_crunch.php

 A revolutionary machine that can copy itself and manufacture everyday
 objects quickly and cheaply could transform industry in the developing world,
 according to its creator.

www.cnn.com/2005/TECH/06/02/tech.reprap/index.html

 The question is _where_ is it gaining ground...
 as a hobby (which I presume is what most c.l.l readers,
 myself included, use it for), or as a substantial outfit
 in a company or in academics, and in the latter I see none
 of it in the last couple years (the almighty Java seemingly
 smothering all and everything).  Any recent success stories
 (i.e. new or significantly increased use of Lisp) here from
 non-hobbyist camps that someone is willing to share?

Sure, CliniSys. Clinical drug trial management. Don’t ask. It is a big problem. Sites by FDA requirement must operate independently of the drug sponsor in conducting trials, which the FDA further want conducted in precise fashion and with elaborate documentation. Investigators are busy people and often screw up. Monitors from the sponsor visit every six weeks to corral things temporarily.

Our mission was to bring everything under control with a thick client installed at the site guiding sites thru the process, enforcing business rules, and basically seeing to it that the whole process runs right while documenting everything and with a precise audit trail of that process and documentation. The thick client also meant we needed a sophisticated application-level partial replication scheme to move clinical and audit data around a wide-area network of collaborating trial professionals.

The hard part is that every trial is different. Even within a trial, the documentation can vary from site to site. On the wish list is customizing documentation to individual patients to support adaptable trials. To make things worse, the documentation can change in the middle of a trial, but data collected under one version of a document must remain associated with that version as other versions come along.

And getting the documentation right means applying arbitrarily sophisticated edits. eg, The pregnancy test result on Visit 2 is required if the gender collected at Visit 1 was female, otherwise it must be "Not applicable".

The final challenge is scaling any successful result to hundreds of trials a year. Existing software does a small fraction of our intended functionality and is so hard to configure to each trial that (a) they can get $500k to do a big trial and (b) vendors max out at a couple dozen trials a year. They hope sponsors will run the software (they call it "technology transfer") and figure out how to configure the software themselves faster than could the vendor. They do worse, and a lot of these vendors go out of business.

So we needed to do WYSIWYG DTP, ICR (scanning and reading documents), our own DBMS, workgroup software to support remote monitoring, and a full browser app for reviewing and collaborating on the documentation set. ie, we needed a GUI, too.

I knew right away that we would have to be able to configure the application for a new trial without programming. Well, there would be a scripting language, but it would be the kind of thing power users master all the time. I also figured out pretty quickly that it would be easier to make a programmable application with a programmable language.

The project was two years old and $2m spent when I signed on to take over software development. My predecessor had just quit. In an exit interview I determined that he was making the right move for himself, but that I would like the gig.

The angel founder trusted me to use the right software, which only makes sense since he was betting $3m on me succeeding. I brought on one other person and in four man years we produced a system that was vastly superior to systems built with tens of millions of dollars. 80kloc Lisp.

People in the business agree our system will revolutionize the conduct of clinical trials. Some nice big partners have joined the effort to make our case to our first customer. That helps since it is a little stange for a three-person operation to have done what no one else even thought possible (which is why they were all trying to use the Web to solve the problem). Making progress, though. Close brushes more often <g> getting both customer and investment.

How did we do it? First, I had done this programmable application thing a couple times before. Second, Common Lisp. Third, Cells. Fourth, AllegroCL’s AllegroStore database. Fifth, AllegroCL’s IDE and Franz tech support.

 Yesterday I was pairing with Patrick, our new intern. He's great,
 smart as a whip, and willing to learn. (When I told him we write tests
 first, he laughed, incredulously, but then I said No, really, I'm
 actually serious, and he listened, and later, he said, Oh, now I see.)
 At the end of a long successful refactoring (turning a clutch of
 static methods into instance methods), we were sort of buzzing and
 didn't want to stop, were casting about for other refactorings to do
 in the same class. I suggested a technique I only just then gave a
 name to, that I've done occasionally on my own for a long time, but
 hadn't yet taught: Zen Refactoring.

 "Just let your eyes unfocus and scroll through the code and look for
 refactorings. Look for duplication; look for too-long or
 too-deeply-indented code blocks. When you notice something odd, don't
 read it, just select it, hit Extract Method (ctl-alt-M), and hit
 random keys for the name. Then focus your eyes again and see what
 you've done."

 I demonstrated. The first time we hit a bunch of print statements with
 repeated formatting -- it worked, but the refactoring was tedious,
 with marginal payoff. But the second time was golden. I saw a blurry
 if-else block; the first arm meandered for 15 or 20 deeply-indented
 lines, the second for fewer; their logic appeared opaque and disjoint.
 But after extracting the first block as a method, lo and behold:

 if (something() || other()) {
  customerId = sdlfjds(x, y, z);
  } else {
    user = someOtherExistingMethod();
    customerId = user.getUserId();
 }

 IDEA had figured out that the result of that meander was a single
 value, and returned it from the new method. It was instantly clear
 that we should rename the extracted method
 customerIdForSomethingOrOther", and extract the whole conditional as
 "getCustomerId". Shift-F6, ctl-alt-M, high five.

 Then it was Patrick's turn. Not quite as much of a slam-dunk but still
 a worthy refactoring. I can't wait to get an incredulous laugh from
 the next one I spring this on...

 When I talk with CEO and CFO types, I generally emphasize that XP /
 Agile projects focus on the delivery of running, tested, actual
 software, along the lines of my article /A Metric Leading to
 Agility/, http://www.xprogramming.com/xpmag/jatRtsMetric.htm