The OO paradigm held great promise in the ‘80s because it provided a much more direct link between the customer space and the computing space due to problem space abstraction. And, in fact, it has substantially improved the maintainability of software. I once participated in a large project to evaluate OO techniques, where we collected data on everything in sight. At the end of day, the initial development took about the same time as procedural development. However, program maintenance took 1/10th the time and reliability increased by a factor of two.
Sadly, I think that today’s OO development can best be described by paraphrasing G. B. Shaw’s observation on Christianity: The only problem with OO development is that it has never been tried. The vast majority of OO applications today are simply C programs with strong typing. In many respects, they represent the worst of both the OO and procedural approaches. They tend to be bloated and slow, which is an intrinsic risk for OO abstraction, as well as being unreliable and difficult to maintain, like procedural applications.
So what went wrong? One problem is that 3GLs are closely tied to the hardware computational models. That makes procedural development much more intuitive in a computing environment. In the OO paradigm, one strives to express the solution in customer terms rather than computer terms. Nonetheless the OO developer needs to be disciplined so that the design can ultimately be implemented on Turing machines. Developing that discipline is not as intuitive as procedural discipline, so it is much easier for the novice OO developer to go wrong. Structured Programming brought order to the chaos of procedural development that existed prior to 1970. However, Structured Programming was quite simplistic compared to the sophistication of OO design methodologies; other than the notion of functional decomposition, Structured Programming was mostly just a suite of hard-won best practices. IOW, design (OOA and OOD) is far more important to OO development than Structured Design was for procedural development.
Therein lies the second problem. Most OO developers today do not follow any particular design methodology. I once encountered a developer at a social gathering. When he found I was an OO developer, the conversation went largely as follows:
He: We are about to rewrite our 18 MLOC C application in C++.
Me: Wonderful. What methodology are you going to use?
He, giving me a look reserved for Village Idiots: Uh, you know… objects… C++.
Me: Hmmm. How much training have you had?
He: We had a one-week course in C++.
Me: Hmmm. Does anyone in your shop have OO experience?
He: A couple of guys did some C++ in college projects.
Me: Hmmm. Are you going to have a consultant to mentor you?
He: No, there’s no budget for that.
Me: Good luck, Huck.
That project was doomed to crash and burn; the only question was how deep the crater would be. It amazes me that companies will pay more to train everyone on how to use a new copy machine than they will pay to train software developers in a major development sea change for constructing their core product line.
The third problem is that in the late ‘80s and early ‘90s, acres of procedural programmers converted to OO development. Instead of learning OOA/D, they jumped right into writing OOPL code. It’s just another language, right? That is the worst way to learn OO development because the OOPLs are still 3GLs and they are still married to the hardware computational models. Those converts were desperate to find something familiar about OO development, so they mapped their procedural design principles onto the OOPL code, mainly because that was easy to do in a 3GL. Thus they created the same C programs they usually wrote, but with strong typing. Sadly, those guys are now writing the OO books.