> I have two applications that both need a class Customer. However, one  
> of the application requires that class Customer have a set of  
> attributes and methods very different from the second application who  
> uses the class Customer for a totally different industry.

Hi Daniel, for me, the key to the answer to your question is the phrase
"totally different industry."  If this is true, it seems there would be little
chance that the Customers would need to be in the same running image, nor would
they need to be developed together.

Therefore I wouldn't worry too much about trying to factor the two Customer
classes into a single, grand Customer superclass, if it won't ever be
commingled in practice.  In fact, doing so could potentially increase cost. 
For example, the two groups of developers may have their own ideas about what
belongs in the generic superclass Customer.  So then you have developers
spending time reconciling code by two completely disparate industries.

Even if theres a remote chance of the two programs needing to co-exist in an
image, you can use refactoring-tools to meld the code at that time.  But keep
it simpler in the meantime.  Remember, if you can solve the problem of ultimate
malleability of software, you no longer need to worry about up-front planning
of "ultimate" classes..  We still need a balance of both, but I believe the
future is in the former.

That's my view, anyhow..

 - Chris