1. Try to do it on your own.
2. Fail miserably.
3. Read Code Complete.
4. Try again, utilizing newfound wisdom.
5. Fail to achieve perfection, but come really darn close.

Maybe I should put that into a haiku. Possibly, something along the lines of:

Re-factoring hurts
Code Complete contains wisdom
I am Grasshopper

The basic idea is that you want to design interfaces to activities, not subroutines. You want to design a way to write using a bunch of "fire-and-forget" actions that map into your problemspace.

For example, I'm assuming you're not going to run afoul of tilly/tye/merlyn and are using CGI. That is a way of mapping actions onto your problemspace, not onto code. That's what I'm talking about.

Identify the actions you want to take, then write a subroutine for each action the problemspace you want to take.

Now, to finish that top-level subroutine, you now have a new problemspace. Keep doing the same thing, over and over. This is factoring.

Where do you stop?

• When you can completely understand each unit.
• When a sub is 25 lines or less.
• When it starts to become silly to write another sub.
• When you feel like it.

You also ask if you should write one sub with two actions or two subs with one action each. It depends completely on your style and how much the differences between the actions matters. I tend to shy away from passing flags to a function. If I have foo() and I pass it either 'bar' or 'baz', then I should have foobar() and foobaz(). However, if the function is making decisions based on the data I'm passing it, then that's the role of a function. *shrugs* I hope that made some sort of sense.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.