Therefore if you wish to avoid digging a pit for yourself, I strongly recommend starting with the opposite assumption. Assume that your program will change. Assume further that you don't know how it will change. With these two assumptions you should now see the benefits of trying to modularize the internals of your program as much as possible. Break it up into functions. Make each function do one thing. Make the name of the function say exactly what that function does. Avoid globals. Use strict.pm to remind yourself of globals you might have missed. So on and so forth.

If you do this, then you will be ready to face the inevitable point where reality meets your optimistic hope that you can just write your program and it will really, truly, be done.

Assume that your program will change. Assume further that you don't know how it will change...

I like this. I had to say that in addition to a ++! As usual, excellent advice from tilly. All too often I get bad lazy and just assume that my software is a rock and an island. The real magic is in the chunnel! Just like MI2.

:)
This was the whole point of the question (which of course gets muddled as brain tries to dump to keyboard). I've got one setup where I know that the spec won't change for a year or two and we worked out what the users really want/need from version 1.0. The next version is to be a lot more presentable and in it's avarice, the department would like to sell it to the other departments, whose setups I will not know ahead of time. Good suggestions, both of you. I'd thought of the easier ones, but strict.pm and OOP hadn't occured to me. I shall be following the latest module thread with interest.

Hmm, where have I heard this before? I thought you were already talking about changes. My experience is that once a program is useful, people will come up with more and different things they want it to do. Assume it's going to change.

There's roughly two different things you can do with a module: define new packages (also called namespaces or classes) with their own subroutines (and maybe local data) and/or add subroutines (and maybe data) to existing packages (like especially 'main'). You can accomplish the same thing with code in a single large program, except that it's bigger, harder to find things, and impossible to re-use that way. By breaking up your program into modules, you can re-use common functionality. If you've designed it right, that is (modules are no guarantee of reusability, any more than object design is).

I use object-oriented design, in which I view my programs as a group of collaborating objects which call on each other to get the job done. Objects have a single responsibility.

Inheritance (@ISA in Perl) can be used where you have common behavior that you want to share between packages. You can put common behavior in one package, and inherit others from that one, adding specialized behavior to each of them.

I don't know your program, but one way to start breaking it up might be to ask where do I have behavior that might change for different platforms or hardware?. If you have several kinds of barcode readers, for instance, you might have a common package ("base class" in object-speak) that several reader-specific packages inherit from. Whether you put these in separate files or the same file depends mostly on how comfortable you are with the file sizes and number of files. It's easy to change later, assuming you don't share lexical variables between multiple packages in a single file.