When life gives you lemons

...make lemonade

Doomed from the start

I don't think you really had a snowball's chance in hell of creating a good product at that large company. The biggest issue seemed to be that you had technical leadership who was more interested in mental masturbation than actually producing a product. But then, you already know that.

What I will give you is a suggestion on how to handle the whole data driven versus business rules in code argument in the future. By the way, OO methodology has nothing to do with it. The real crux of your problem was that you wanted the business rules in the database, whereas the smalltalk guys wanted them in code. OO doesn't care where you put your business rules.

You shouldn't go away with this experience thinking that OO is bad and procedural/data driven is good. Both approaches have their place, sometimes within the same application, but the key is knowing when and how to apply each one. The lesson you should walk away from this with is that smalltalk guys talk big, but are really compensating for their small*****. ;-)

Anyway, if you've identified something like where business rules are stored as 1) being very important to the success of the product and 2) a topic of contention amongst the technical staff, I would recommend bringing it back to your product managers or sponsor and getting them to help set requirements. If you have a requirement that your business analysts (product people) are able to change rules by modifying the database, then you get your design the way you want it. The smalltalk guys get overruled.

Use your customer or sponsor to play the bad guy once in a while. Less wear and tear on you. After all, they are the ones who have to live with the ramifications.