In every project I take on, I reduce the "pieces" of the project down to individual lumps. Several reasons. One is to find overlapping functionality and stop duplication of efforts. Another is to make development/debugging easier as I am now debugging small pieces of code. The next big reason is that I can then dynamically load (in most cases) only the pieces I need for that individual run (or CGI hit).

I find that all of these things improve development time, quality and my teammates (if I have any) ability to contribute to what I am focused on. In the long term, it promotes reusability, scalability and maintainability (and puts me into a better position with my management).

The calendar based applications I have written in the past always had many functions, though only a few were used on each call. I was able to write much faster functioning code (did not have the ability to use mod_perl or anything similar in most cases) and we were able to quickly extend core components to the "new" requests that inevetiably come in (come to mind) after a neat new tool is put online.

In a nutshell, many small pieces (with very few exceptions in my experience) almost always work better than large chunks of code.</P.

There is a simple way to load an unknown object (module) at run time. Rather than have a bunch of use this; use that;s up front in my code. For me, using a dynamic system has cut down on overall loading, memory, time, etc.