When life gives you lemons

...make lemonade

A project gone bad

One reason why I'm leery of the buzzword of the day.

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.