>>For example if I create a UDF that formats a city line for an address, well that I would probably put in a PRG. But if I have code that calculates the customer balance from the transactions, that I put in a customer class so that the customer object is responsible for its own calculations.
>
>Seperate prgs huh? Gotta love it when the simple (but effective) is not so obvious. I'm with you on the issue of having to carry around a lot of baggage porting proc files from one app to another when most of the functionality is not needed. I'm going to go to your model for my own development. One disadvantage though would be administration on a large system with a larger development team. Unless you're working with folks who document and administrate well, it would be a nightmare trying to keep track of prg functionality and which ones ship with what app. It definitely wouldn't work in the shop I'm in (sad to say). Thanks for the tip. You just changed the way I think about prgs.

My custom is to have all those utility PRGs in one common directory, and any app's init sets path to it. Then the project manager includes only those needed into the app. Yes, it takes some discipline, but after several years there's a well-lubricated practice on what and how gets included there (meaning that I do almost all of it, and for the remaining 2% the guys ask me if it's OK :).