In general, it's a good idea to declare variables using my instead of using a global or using local. It forces namespace and scope awareness and eliminates pernicious bugs caused by same-named variables with different scope. Practically anything you can do with a local or global variable, you can do with a change in design using my, and you'll get a much more robust design.

Also, in general, avoid exporting variables from modules. Exporting methods can sometimes be OK, although I still think it's better to say

use Foo::Bar;
...
my $barian = Foo::Bar->baz();
[download]

Variable and method names should be communicative of the intended use; it's better for a name to be long and communicative than short and cryptic.

Document, document, document.

Also: I'm astonished no one's mentioned using functional spec's and test suites before now. (Visit this Joel Spolsky article and scroll down to the second headline, "Painless Functional Specifications," for information on the former; perldoc Test::Harness and perldoc LWP::UserAgent for details on the latter, and on user agents which are also an enormous boon to web developers seeking a means of testing functionality and sounding the alarm when things go wrong.) Writing a spec before the program saves loads of time and heartache, as well as keeping the MBA's and the techies on the same page. Similarly, fleshing out the spec into a test suite before any code gets written -- and continuing to flesh out the test suite while coding -- reduces the likelihood of bugs, increases confidence in the final product, and makes a predictable timeline actually possible. Ideally, you want to test as high up the call chain as possible, drilling down into the nitty gritty only when -- and to the extent that -- the need presents itself.

There are even times where it can be helpful to write a tiny program whose specific purpose is to test the syntax or the effect of some (for you) uncharted Perl functionality. I did this in my formative Perl years and it saved me an enormous amount of time.

Oh, and also it helps -- particularly if you're working in a country whose primary language is English -- not to comment your code in, say, Croatian. (Don't laugh, I actually inherited a project some years ago containing some sections of code in which this had been done!)