OOPS!

or : Where Did Object Orientation Go Wrong...?

There is no silver bullet: Object Oriented Programming has failed.

What? But surely the world and its dog – Microsoft and Sun, naturally – are object-oriented … C# (which some cynics would argue is little more than a Java clone) and even Visual Basic (God help us all!) are class based. Well, so they might be, but in the twenty or so years since object-oriented programming emerged from the universities, there is not one single documented, cast-iron, nailed-to-the-ground, proven case study that OOP works.

On the contrary, there is solid evidence that OOP doesn’t work. Just look around you at the numerous failed, over budget disasters in the IT industry. If Airbus or Boeing built aircraft like the IT industry builds software, aircraft would constantly be dropping out of the sky.

Ah, but maybe these IT disasters wouldn’t be such train-wrecks if the IT professionals used OOP practices properly?

Possibly… But let me give you two cases from my own experience. First was the company that was going to build a new OOP banking system. Great idea! Just create a banking class library and use it to build banking applications like cars off a production line; or like shelling peas - or whatever inane simile you want to come up with to disguise the lack of any deep analysis. Or if the truth be known, any analysis at all: this is the world of banking. The problem was (and is, and always will be) that processing dosh does not correspond to an OOP paradigm.

For example, there’s a little thing in the banking world called “reconciliation”. It means tracking down and fixing the host of small errors introduced by the users of the system - people, in other words. Now just try to find a real person in an OOP design. Hmmm - difficult. Anyway, reconciliation fundamentally requires cross-referencing, cross-checking and often painstaking detective work. At the bottom, this requires looking inside what is going on – which is directly contradictory to the whole idea of OOP.

None of the designers working on the class library thought of this, of course. Reconciliation? That’s what clerks do! Of course, the great OOP banking system was delayed - and delayed. Delayed because nobody who had the misfortune to use the class library could work out what the hell it was doing. I don’t know the end of the story, whether the great OOP banking system was ever built, or whether it joined the 70 percent or so of failed IT projects. Somewhat disillusioned, I left for pastures new.

The second example is entirely down to me. I was working on fixing a bug in an object oriented Perl system. Yes. Perl can be made object oriented; it isn’t elegant (think of camels dancing) but it does work. I noticed the error low down in the class library and like a good programmer fixed it, got it tested and thought no more about it.

The next week, I had a call from a puzzled user who was not connected with the part of the system I’d fixed. He had noticed a change which he hadn’t authorized – it wasn’t a serious problem because it worked out ok – but it was different and that’s why he was concerned.

Then it hit me!

What I’d done was to modify the behaviour of a base class. And this behaviour had then propagated with effortless ease through the whole damned system. But, with financial systems, this is a no-no. In a typical financial system, all responsible users have to sign off on a change before it goes live. After all this is real money we’re taking about here. Especially if it’s the bank’s own. With this particular system, that sign-off involved users in most of the capitals of Europe!

The point is that when you modify a base class, you potentially change the entire derived class functionality. So, you have to re-test all of the down-stream bits of the system. While you can easily find the ancestor of an object, it’s not so easy to find the descendants. It’s even less easy (to err on the side of understatement) to find the users of the descendent systems and get them to re-test, especially if the bug didn’t directly affect them in the first place. Eventually, I had to put the bug back into the base class and override the troublesome code in the one derived class that was the cause of the problem.

Great stuff, OOP. Truly world class!

So what’s the silver bullet then? That’s the point – there isn’t one, and there never will be. To understand that, just dump all your books on OO methodologies and read “The Mythical Man Month” by Frederick P. Brooks. More of Fred Brooks next month. OOP is snake-oil.

June 2005