It depends tremendously on the task at hand.

If I'm doing something that will take less than half a day, and be used only once or twice, just diving in and doing it is an excellent approach. Even if you find out that your script is tremendously useful and is used all the time, you've only invested a half-day in your prototype, and can rewrite it without throwing out a ton of work. No need to enter analysis-paralysis - perl is very good at rapid prototyping.

However, anything that's going to take longer than that, needs some more thought.

Sometimes, you'll have a good idea what you want - particularly if you're rewriting a legacy appliction, for instance. Getting a good database schema and object design done in advance has proven to be a worthwhile approach. Write this stuff down - it's very handy if you're working with other developers and/or QA engineers, and helpful for you to flesh out your ideas even if you're not. Being able to write a technical specification is a job skill that will never be a waste. Have someone else take a look at it. If your design looks good, handles the scenarios you can throw at it, and solves your problem, go ahead an implement it. Preferably little testable chunks at a time.

But, often we don't know what we really need when we start. If possible, design a prototype. You'll learn a lot more by solving a small, representitive part of the problem set than by just thinking about it. And you can get feedback from the customer that you're on the same page - few people really can tell from specifications what it's like to use a piece of software. After this, you're in a great place to do actual design work.

It's almost always worth the time to design objects, rather than throw them together, because you'll spend less time in maintenance. All software evolves in the business world, and the best designed software will eventually be full of hacks and special case code and need to be redesigned, but you can make it a lot farther off with some good investment of time up front.