I'm not knocking wish lists. They are where all software starts. It's just easy to fall down the rabbit hole and keep adding stuff to the wish list until it becomes a snarled mess you can't possibly turn into code.

Trust me, I'm speaking from experience on this one.. ;-)

It's also cool to need something ASAFP because The Boss (and a wife definitely counts) wants to see progress. But when speed counts, you need to be very careful about limiting the scope of your work. Nothing can kill a schedule quite the way feature creep can.

One of the most useful programming axioms I've ever tattooed inside my eyelids is: anything is better than nothing. It sounds like a tautology, but having worked many projects in many settings, I've found that even the ugliest kludge will take you farther and faster than an empty source file and a bunch of grandiose dreams.

Dreaming is easy, and programming is hard. Therefore, dreaming (usually called: 'planning', 'collecting requirements', 'designing', etc) is a great way to escape the ugly reality of having to write actual code. Not that I'm against planning and design -- far from it -- but if you don't know how to turn what you're doing into code, you're not planning or designing. You're daydreaming. Planning and design are every bit as hard as programming itself, and the only way to tell whether you've fallen into random speculation is to try turning the work into code.

If you can't even reduce your ideas to a set of nested print() functions:

    sub do_something {
        print "now we want to do this.\n";
        step_1();
        step_2();
        step_3();
    }
    
    sub step_1 {
        print "  handle this part of the job.\n";
    }

    sub step_2 {
        print "  handle the next part of the job.\n";
    }

    sub step_3 {
        print "  handle some other part of the job.\n";
    }

    do_something();
[download]

People fall into the trap of pseudo-planning because they feel overwhelmed. They have a great big wish list, and writing minimal prototypes just seems.. unworthy. So they try to turn the wish list into a map of the final product, and busy-wait themselves into oblivion.

Don't try to plan software all in one go -- that's not how we build the stuff. Piet Hein, mathematician and all-around genius, wrote little poems called 'grooks' as a hobby. Donald E. Knuth, arguably the world's foremost source of programming wisdom, quotes one of them frequently as the essential model for software development:

"The road to wisdom?   Well, its plain and simple to express;   Its err, and err, and err again,   but less, and less, and less."

If you need to be fast, zero in on the smallest number of things your program can possibly get away with doing. Make those work, then start thinking about other things you can add. Get used to iterating through the cycle:

• make it work
• make it correct
• make it fast

where each 'make it correct' pass gives you enough foundation to keep the next 'make it work' pass from becoming a nightmare. Leave the 'make it fast' stuff for last, because few things screw up a program worse than 'optimizing' it before the part you're tweaking has been set in stone long enough to acquire a few layers of pigeon crap.

That cycle will zero in on usable, well-built code much faster than top-down design based on speculation instead of code.

The nested print statements give me the look of using some of the test modules on CPAN.

This is an instance where it is a good idea to write the test plan before writing the code. There are various modules on CPAN which can help here, including Test::Harness and Test::Unit

Supersearch gives some discussion including Unit Test libraries, opinions

In my opinion, deferring writing the tests until the end is almost as bad as deferring putting comments in the code until the end. Designing tests focusses the mind on what you are actually trying to achieve.