When life gives you lemons

...make lemonade

But we have a working product!

The Smalltalk guys didn't like C++'s object model, so they immediately set about to using this odd design methodology called "exemplars" to try to force dynamic class creation on C++. Of course, none of the original coders had a clue about all this. I was the most experienced OO guy, and I barely did. Still, it was interesting...but the sort of thing I'd play with for a year or so before using it in real work.

We then proceeded to spend the next three months arguing about what should be classes. Our group argued that much of the knowledge should be stored in tables, and not in code, but we were constantly overruled by the Smalltalk guys, who did not seem to understand the concept. (We later learned that these guys had little production experience, and mostly worked in more academic arenas.) They wanted every little thing in the code, so that, for example, to create a system to take an American Express card, you'd make a subclass of the CreditTender object. (As opposed to our system, where you'd just add a table entry.) "But that's not OO!", they'd say, as if that were the only constraint.

Of course, this directly contradicted one of the design goals, which was to create a system that could be modified by non-technical people, so there was lots of fudging. I once even heard it suggested that the product people could be taught to program!

Anyway, after three months of this, nothing had been produced. Nothing. Not even a design document. Just lots of wrangling about what the "right" object hierarchy was.

Then they sent us packing. Our company went under, taking our working, but not completed, POS system with it.

The big company did not make its one year deadline. It was well over five years before it released an initial version. (With forty people...we'd created something salable in two years with five people.) That version was just slightly more functional than our original one, and was far less flexible. You had to recompile to make almost any change. Want to take layaways? That's a recompile. What to take JCB cards? That's a recompile.

The product was a marketplace failure.

Buzzwords are not goals. If you let buzzwords overrule your requirements, you are in for a world of hurt.

Eeek. Your team fell for worst play of all times: the Sword & Shield. This is when a company wants to do something computer related and since they have the underlying belief that all computer people are no good charlatans bent on ripping them off, the company sets a mandate to have a sword and shield (two teams with adverse objectives, where both are held in place by the fear of the other).

So your code was 35% OO. Did they share with you how the hell they came up with that number? Or did the other team 'assess' you and come up with it? You claim they brought in the other Smalltalk group after the code audit? Who performed the audit? Bah it doesn't matter. It seems to me that what you needed to do was have more meetings with the people who would receive the final product and have them spell out the design for you better. If they could not do that, then you have a problem with the customer that is really scary.

Something else occurred to me reading this. You need to read Scott Adams' "The Way of the Weasel". And by God, get a more fierce band of weasels working for you in the future. Because you're a tech guy - you are automagically at a disadvantage to high level business types that will steer your project into the ground.