Dermot Hogan thinks that OOP is the problem rather than the solution:

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.

Here's a tip Dermot - we haven't found anything that works that well yet - the various non-OO systems out there haven't exactly covered themselves in glory either. Well heck, none of this is a huge surprise. The people doing development in Java and C# now - for the most part - never actually learned OO. They were C programmers who picked up a C++ compiler, and then went with the syntax flow. Along the way, their OO knowledge hasn't really grown any.

That's the basis of an awful lot of development projects, and it's a reason (hardly the only one) why many fail. Sure, Smalltalk projects fail too - I'm not about to claim that Smalltalk is a magic wand that will wipe away all your problems. However, it is simpler, cleaner, and easier to develop with. Which means that at least one of the layers of complexity in software development is lost when you use Smalltalk. In any case, back to the article - here's Dermot's great example of OO's failure:

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.

Sigh. It would be nice if he identified the actual problem here. This issue has nothing to do with OO, or procedural, or functional (etc.) development. It has to do with non-interaction with actual users of the system. You know, that real world customer thing that the agile folks like to talk about. I'd bet good money that the designers of Dermot's system walled themselves off and designed this thing in glorious isolation - and were then stunned when they discovered all the hidden use cases (like reconciliation). Surprise! Not dealing with actual users has consequences. If Dermot fails to realize that, then woe betide the next system that he works on, because it will fail for the same reason, and he'll be utterly stunned.

Next, we find that Dermot has an eye for the obvious:

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 descendant 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.

I guess the concept of a change request in a mission critical system is an utter mystery to Dermot. Heck, a lot of things are an utter mystery to him. Say his system had been fully procedural, and lots of components relied on a few shared libraries. Now, say you changed the behavior of one or more of those libraries. Wow! We have the exact same problem, and there aren't any objects in the vicinity! Perhaps the problem isn't OO, and it's instead a matter of process. Too bad Dermot isn't capable of seeing that, and instead wants to find something other than his own limitations to blame. See, here's the final kicker:

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.

If he'd actually understood any of what Brooks wrote, this op-ed piece he wouldn't have happened. OOP isn't snake oil; it's one possible solution to the software development puzzle. Simplicity and consistency help a lot (which is where I think Smalltalk comes in), but hey - I don't think anything will help Dermot's development problems. He needs to go back to basics, and figure out stuff like use cases, listening to end users, that sort of thing. Until he figures that out, it really doesn't matter what he uses.