I interpret your meditation as meaning "There's no such thing as a one-off program", when applied to IT. If so, this sentiment is laudible.

However, the word design has connotations when it comes to software, as design is quite downstream of many activities.

First of all... Requirements, requirements, requirements!

What problem are you trying to solve? It may be, that uniqueness is a requirement, in which case you need to design for exactly _one_, not zero or many. For example Class::Singleton.

I think a more important focus is to design for the future. Try to anticipate future requirements.

• Code reusability
• Ease of adding options
• Maintenance: what about the poor *** who is stuck with your code after you leave?

My recommendation is to get a good book on design patterns. Fellow monks, can you recommend any?

--rW

Not sure about a Perl-oriented one, if such a beast exists, but for a general guide I tend to use the almost-standard 'Design Patterns' by Gamma, Helm, Johnson, and Vlissides. Examples in this are in Smalltalk and C++, and some patterns don't map too well onto the Perl brainspace. Admittedly you do end up spending a lot of time looking at the examples and going 'Now what would I use this for myself..?", but I find this with many architectural/design books.

The only Perl-specific Design Patterns resource I've yet seen is the heavily incomplete webpage at http://www.patternsinperl.com. Some nice discussions on a few patterns, but not too much as yet.

Care to elaborate a bit more? This is rather open-ended, but since some of the best discussions start this way, I'll randomly apply it to a few things.

Programming Languages - TIMTOWTDI, especially to do with minor syntax issues. Plan for many different people's personal tastes and don't restrict things needlessly.

Bugs - You'll definately find more than one, so use good programming practices to reduce the number of them and enable you to fix them faster.

Documentation - Projects tend to grow faster than documentation can keep up. Keep your code well documented so that others can reuse it and learn from it (see this node for more on the commenting debate).

These may be a bit of a stretch from the original meaning of the node, but oh well :).

If you design for 'zero or one', you're building an assumption into the program: "this item can only come in two possible quantities: zero and one." That invites the question, "what happens if your program sees more than one?" to which the usual answer is "it falls over and dies.. possibly trashing the database (or other persistent data) as it goes."

Designing for 'zero, one, or many' means you've covered every possible combination of inputs. It means your code won't fall over because it sees input you didn't plan for.

Except when designing user interfaces. Many of the worst interfaces are generated when programmers think in terms of 0, 1 and infinity.

Not to be negative, but what about -1 and negative many?

What about fractions, irrational number, complex numbers, infinite numbers of things?

Saying that the arbitrary set of (0,1,n > 1) has some magic general quality is misleading in my opinion.

You may as well be saying "you should think outside the box" when designing software.

It's all about the specific details, and every piece of software is full of them. The best design philosophy in my opinion is to keep your eye on the ball and focus on doing the minimum amount of effort (laziness) to do the specific job in front of you as quickly as possible (impatience).

Just my 2 grand. (hubris)

-Andrew.