That's a good way indeed...
Rather that's a good point to start with,
but take care, this will only give you a way to go on further.
It won't assure you to reach what you want...

Breaking a problem into the right smaller parts isn't so obvious,
there are often several ways and few good ones...
Often the difficulty is more to make the good choices
than just breaking into several simpler tasks.

Let's take a dumb example (I'll let smart people find smart example ;-) :

You have to write a small program to make two host communicate (in batch) via several means; what will you do ?

• Write a client and a server ?
• Write a single client/server prog ?

Depending of the constaint the first one may not be so stupid
(even if the second one is more likely...)

Then as the prog has to be configurable,
writing the prameters handling part you wonder : how will it take its parameter ?

• Via the command line ?
• Via a conf file ?

And those of you who just think
'If the amount of argunents is important just use a file
otherwise the command line is the best'
could just miss several possible aspect (security, file constraint...)

Now that you have your data, you'll write the com routines;
of course you know what protocol to use :

• TCP ?
• UDP ?

...

Of course this example is dumb, the (few) questions are over-simplified
but the idea is although apparent :
Breaking into smaller parts is usually easy
but making the right choices doing so isn't so obvious
Decomposing a client/server prog into several parts is easy but depending on how you do it,
it will be more or less easy to maintain, easy to upgrade, easy to understand...

The choice of your structure, data, algorithm (among a lot of other things) is important too, in my humble opinion.

"Only Bad Coders Badly Code In Perl" (OBC2IP)