>>Hi Naomi,
>>
>>I concur completely with Tracy's view of things. Let me paraphrase it into my idea of fitting "programmers action" <g>:
>>You can look over the other frameworks and propose for one of the framework to be used as the base classes for your tasks as well. Ask all other authors which level they think is stable enough to be re-used (and get a feeling if they think this is a good idea <bg>). Leave all the modification of the foreign base classes to the original author for at least 4 months (you can always override methods at your own layer between frame-base and application level class - keep all your "framework" ideas separated at such a level for now) until you have acclimatized into the new job. By then you should have enough suggestions that the "best" of them is certain to be included into the framework WITH the support of the original author, not against it as it probably often was in your old job.
>>
>>This way you show you tried to avoid building a new redundant level of base framework classes - even if they decide otherwise (there is also a danger in reusing "semi-base" classes if they are changed too often by the author) you will be in the green. This way you can work on your tasks while reusing existing code. Even if you believe some things should be implemented differently, you can do that for your tasks without disturbing other applications and later discuss backporting some of the enhancements. I personally find such an approach more productive, since nothing spends time as unproductive discussing on possible ways to implement.
>>
>
>Hi Thomas,
>
>I wish it would be as easy as it sounds. Here is what I found: each developer has his/her way of doing things and copies programs and classes from one application to another every time they need to create a new project. One of them explained me his concepts and sort of was forcing me to follow the same steps. The other developer told me to grab anything I like from her applications and implement it. Finally there is another developer whom I haven't spoken at all and didn't see the applications (perhaps for the best to not confuse me further). There are only two main directories under each application folder: Data and Source.
>
>This goes against everything I used to work before. I always had base classes, programs, graphics in one common place (with appropriate subdirectories) and each application just subclassed the base.

Personally, I always have 'data' and 'source' with base classes (not subclassed). It's easily justified by consulting specifics, because every client is a distinct entity, so it doesn't want to be 'subclassed'.
However, in your case it's also beneficial to keep every developer separated, just to avoid a mess to conciliating different styles. Basically, common architecture can be implemented from organizational top only (i.e. pushed down the throat of individual programmers) and it's detrimental (imho) for working environment and developing individual skills, though it could be Ok for business purposes.