Keep the modules separated enough that they don't need to know so much about each other (this is de-coupling). They should only talk to each other using well defined interfaces (this is data hiding). Doing this will make it possble to keep it "small enough" in each module and the overall complexity low by not having to know the big picture everywhere.

Something you actually (hopefully :) did but maybe never thought about when scripting is analysis and design. These have to become more explicit when developing larger applications. You have to take a step back and get an idea of the structure of your application, what subsystems and modules it consists of and how they tie together.

You have to document this somehow and communicate it to other people, maybe fellow programmers, maybe sysadmins, maybe a project leader, maybe yourself six months from now. Pictures are good. Good writing is good.

When the script grows, things that can go wrong add up. Depending on your application, it may need to log things for debugging purposes, and more importantly for outright errors. When things go wrong, abort early, log what happened and notify the programmers (that would be you) by email. This way you'll know when, in your production environment, things didn't work out as planned. This will happen. Promise. Sorry :)

/J