About twelve or thirteen years ago, I worked for a small Point of Sale company. Their original product was written in very poor C code and during my first stint there, I had made my opinions on that system well known. Eventually, I left that company, partly because I tired of writing old K&R style C for a Z80, and took a job writing more standard C code.
About a year later, I was hired back to take a lead position on a new Point of Sale project. The project was to be an entirely new Point of Sale system, designed from the ground up to be flexible and easy to maintain. It was written in C++, but by C coders. The choice of language mostly had to do with C++ being the "hot" language. (And part of this had been because I'd been selling the management C++ when I had previously worked there.)
I was brought in for a couple reasons, partly political, and partly because though I'd never done C++ code professionally, I had done a bit with it in college, and was known as an advocate. At the time, very few coders had much experience. C++ compilers had only existed for the PC for a couple of years.
At the time, the system was not complete. The base design was there and my job was to take the project to the customer release. That mostly meant developing particular features needed for the first installation, along with general debugging. There was also a mandate from on high to "make sure it is object oriented" for reasons that were not made clear.
The code was quite good. The C coders had, I thought quite rightly, played it fairly conservatively, using C++ mostly as a better C, being cautious about what language features they used. As a result, the system was very C like. But it worked well, and was relatively bug free. It was a data-driven system, so that most of the functionality of the system could be changed by database entries.
We made our first deadline, delivering the first customer release on the expected date. During that time, I had personally worked on adding new classes, where it made sense. (I still remember the first classes I added, as part of the SQL interface.) This went fairly well, and soon the C coders where doing real C++ on their own, following my examples. But despite this, the program still had a lot of C-isms. But we weren't particularly concerned, because the system otherwise met our goals. It was quick. It was lean. And most importantly, given our particular market, it was flexible. Most common changes could be done without even hitting code, and by product managers, not coders.
At the time, about ten man-years had been invested in the product. We estimated that with another ten to fifteen man-years, we could complete the entire thing as a generic point of sale system. We also figured that we'd slowly improve the OO (object oriented) nature of the system. (The word "refactoring", of course, did not yet exist in the programmer's lexicon.) Since the first customer release (a two man-year task) came right on time, to the day, I'm confident that this estimate was accurate.
We were a small company, with small company money issues. Our CEO managed to sell our new project to a very large company. This very large company also had a point of sale system near the end of its lifespan. So we sold our not-yet-complete system to be the basis for their new one. They were in a hurry. They wanted the project completed in a year.
No problem, we thought. The five of us were flown out to meet with the thirty to forty people they had to work on the project. Given the scope of the project, this should be a snap. The only fly in the ointment being that none of their people knew either C++ or object oriented design. Still, we figured, thirty people, ten man-years, no problem. We'd managed to keep things on time in the last release despite the C++ learning curve.
They also wanted it to be "object-oriented". They did a code audit on our stuff, which came up mostly positive, but with the caveat that it was "only 35% object oriented".
The big company then decided that this wasn't enough. They were going to instead design their project from scratch, not using our working version, but using us for our expertise in the language. At the time, I found this a bit paradoxical, simultaneously telling us that they wanted us for our OO skills, and that our work was not OO enough.
But we were not the only OO expertise on the project. They wanted object oriented design expertise. So they brought in some Smalltalk guys from another branch of of the company to teach us object oriented design.
"But we have a working product!", we said...
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.