From a design stand point there are so many different schools of thought on this and none of them is right for everyone. For me it seems to work best to work mostly in reverse, that is what do I want in the end vs. what do I need to build first. To do this I write down my understanding of the task at hand. I try to make this as detailed as possible. From there I try to determine the following

• Recurring items
• Related items
• Areas that I know the least about programmatically
• Areas that still don't make sense
• Lifespan of the item I am creating
• Target audience
• What data I am manipulating and what container it should be stored in.
• What modules on CPAN can cut my work time down

I then take the recurring items and group them into modules and then do the same with the related items.
The areas that I think are going to be difficult to program are mapped out in great detail on paper to determine possible approaches and weak points before I am looking at code and confusing code with process.

If an area still doesn't make sense then the requirements are bad and the person who created them needs to be consulted. If you created the requirements then good luck :^)

Lifespan takes on different forms. One is how long the code will be in use, the other is will the program run and end or will it operate in a server mode that effects caching and memory usage. Each of these will effect how you will approach your coding.

Target audience is involved because this may determine how elaborate the user interface needs to be and/or where possible shortcuts can be taken.

The container for your products data can really haunt you. Lifespan comes into this as well since again if it is only a temporary storage system that will be disposed of you don't have to as concerned. If the product and its data will have a long life you will want to take into account how the data will be interacted with in the future. Does it need to log things? How long do I think the storage method I am using will be available? Is it easy to interact with from other languages? There are many more questions and vary from project to project.

Are parts of what I am doing on CPAN? This is more then important in my opinion, use CPAN code vs. reinventing the wheel. This can also be one of the tricky parts as well, since often times module names seem to fall under three categories.

1. Right on, tells it like it is
2. The correct technical term, but in reality most people know it by another name or might not know the correct technical term.
3. What was that person thinking. The name doesn't fit the function at all and it is usually luck or word of mouth that brings you to this type.

So I guess planning is what you should do first.

Hopefully somewhere is that brain dump someone fines something useful. If someone thinks it is useful enough to refine and make a meditation out of let me know, but I am following my rule and thinking the lifespan isn't long enough for me to refine it any further. :^)