This article looks at the goals of object-oriented technology and asks to what extent those goals were actually reached. The pioneers of object technology and object-oriented programming set themselves very high goals, goals that can only be measured to a limited degree. They wanted to multiply productivity, cut maintenance costs to almost zero, promote reuse and make software portable. As a number of empirical studies have shown, these goals were reached only in part. Like every IT technology, object technology was oversold. Still, it had many positive effects on software development, above all on reuse and portability. In the end, going down this road was worth it. But we can’t stop there. The search for the holy grail of software development goes on.
The Goals of Object-Oriented Technology and Object-Oriented Programming
If we want to judge whether object-oriented technology succeeded, we have to measure it against its own goals. According to the early champions of the movement, the main arguments for adopting object-oriented methods and programming languages were:
- Higher productivity
- Lower maintenance costs
- More reusability
- Better portability
This article examines these four goals and checks how far object technology (meaning OO analysis, OO design, OO programming and OO testing) has come toward each of them. Has object orientation delivered what it promised? At the end, after looking at each goal in turn, we come back to this question and try to answer it.
Goal One: Higher Productivity
According to Tom Love, founder of Productivity Products International Corporation, object orientation was supposed to bring a major leap in productivity. In the May 1987 issue of Datamation, he wrote:
“Structured programming was only a small help. It provided only 10-15 % improvements. […] Object oriented programming stands ready to provide such needed improvements because it offers a radically different, more intuitive way of conceptualizing and building systems …”
At the first OOPSLA conference in Portland, Oregon, in 1986, more than 1,000 followers of the new OO development method showed up. All of them were firmly convinced that it would revolutionize software development. Every problem developers had struggled with for years would simply vanish. It would be possible to move effortlessly from requirements analysis through architecture design to writing code. The old semantic barriers between the levels of abstraction would disappear. The path from requirements to code would not only be much faster; the resulting code would also contain far fewer bugs than before, which meant less testing effort. That is what leading software technologists of the day believed.
Positive Characteristics
One of the strongest advocates of object technology was David Thomas of Carleton University in Canada. He was involved in developing the Smalltalk language and was convinced that object orientation would significantly increase software productivity. He wrote:
“We have been convinced since 1975 that the object-oriented approach to software development is the best of all known techniques. It will revolutionize programming.”
By joining data with the procedures that process it, all the problems caused by separating data from algorithms would disappear. Complex systems could therefore be built far more easily from these combined building blocks (data plus algorithm), and developers would have more ways to combine them. According to Tom Love, separating data from procedures had been one of the biggest drags on productivity in software development up to then. Removing it was a major achievement of object technology.
Encapsulating data and functions in self-contained objects makes it possible to take these objects out and move them elsewhere. Objects only respond to messages from outside. They receive predefined requests and deliver agreed results. How those results come about stays hidden from the outside: information hiding. External procedures have no access to the encapsulated data and functions. Instead, they get a well-defined interface that governs the exchange of data. This property makes it possible to assemble large systems from many tiny building blocks. If most of the building blocks are prefabricated, most of the development effort disappears along with them.
Inheritance is another factor that drives productivity. Data and functions are programmed at a higher level of abstraction and passed down to the lower levels, where they can also be modified. This saves the developers of the lower-level code units from having to program that data and those functions from scratch.
Redundant code had been another drag on productivity in structured software development. More than 50 percent of the code was redundant. Developers copied code and changed only a few lines. With inheritance, they could take over the original code without moving or changing it. Rebecca Wirfs-Brock puts it like this:
“You don’t destroy the original code, you just extend it and build upon it… Inheritance makes it possible to define complex new objects without the bother of writing everything from scratch.”
On top of these productivity gains, object-oriented programming adds flexibility through polymorphism. In procedural systems, the coupling between modules was usually very rigid. Which module called which other modules was fixed statically. There was even a special link step that bound the modules tightly together into a run unit. If developers wanted a different combination of modules, they had to put together a different run unit.
COBOL and PL/I did have dynamic calls, but they were rarely used because they were awkward and hard to follow. You had to link all potentially callable modules together so that the program could decide at runtime which module to call next.
In object-oriented languages, it is much easier to identify the method you want through its class, and only at runtime. That makes the code far more flexible and allows more combinations of bindings. The feature is controversial, but it has its advantages: code with deeply nested case statements can be simplified with polymorphic calls.
Positive Experiences
Did object technology actually make development more productive? There is no clear answer. There are both positive and negative reports.
On the positive side, graphical user interfaces such as Rank Xerox’s multimedia spreadsheet for the U.S. CIA and IBM’s TPF2 timesharing system would not have been possible at all without object technology. Ann Hardy of Key Logic states:
“The TPF2 software has been written in an object oriented version of PL/I. We could not have built the system without it.”
The same goes for Apple’s Lisa and Macintosh. Both products would hardly have been possible without the new development technology. This underlines the fact that for some types of applications, there is no alternative to object technology. In other fields such as telecommunications and multimedia, object orientation is indispensable as well. Nobody would think of doing it any other way, unless with an even more advanced form of programming such as aspect-oriented programming.
But traditional data processing has its share of productivity success stories too. By using C# with the .NET framework, an automotive supplier achieved a 200 percent increase in productivity, mainly by using prefabricated components. Java projects have achieved similar gains, for example at Sparkassen-Informatik (the IT service provider of the German savings banks) in developing new booking systems, or at Allianz insurance in replacing old collection systems.
These success stories speak for themselves. Applied correctly, object technology can raise productivity and speed up development. Critical voices get their turn at the end of this article.
Goal Two: Lower Maintenance Costs
Even more than higher productivity, object technology aimed to lower maintenance costs. During the 1980s, the cost of keeping existing systems running kept rising, and by the end of the decade it made up more than two thirds of total costs: maintaining and evolving old systems cost twice as much as developing new ones.
Proponents of object technology claimed that this was mainly a result of procedural programming. Programs had become too large and too complex. Maintenance also suffered from poor code quality; the code could only be understood with great effort. Introducing object orientation into design and programming was supposed to make everything better. Maintenance costs were to be cut in half.
What Drives Maintenance Costs
Software has three dimensions: size, complexity and quality. Together, they determine how maintainable a software system is. The new object technology promised to reduce the size and complexity of software systems and raise their quality. Maintenance costs were supposed to fall as a result.
The very claim that maintenance effort depends on the properties of the software itself was wrong. Maintenance effort depends on many factors, including the maintenance environment, the skills of the maintenance staff and the tools they have. So changing the software can only have a limited effect on maintenance costs.
Let’s start with size. Procedural systems really were too large, and above all their building blocks had grown too large. The larger the building blocks (modules and procedures), the harder they are to understand. The main cause of this bloat was copy and paste. Programmers moved large sections of code from one module to another and changed only a few lines. That’s how code used to be reused. Changes, however, then had to be made in many places. Instead of creating new subroutines, developers extended the code where it was, so it kept growing. With inheritance and small, reusable classes, object technology managed to cut the amount of code considerably, but at the cost of complexity.
Complexity is determined by the number of relationships between code units. Object technology does make the individual units, or procedures, smaller, but it creates more of them. Proper OO systems consist of a large number of small classes, each with a limited amount of data and functions. Just managing all these source units takes a lot of effort. Much more serious, though, is the large number of relationships between them. Every inheritance, every association is a relationship, which means one more dependency. The more relationships between the building blocks of a system, the more complex the system.
Then there is the dependency on other developers. The developer of a class that inherits from one class and uses another depends on the developers of those classes. If one of them drops out, for whatever reason, the dependent developer has to take over their code. One of the authors worked on a project where pure object orientation was abandoned for exactly this reason. We can conclude that OO systems have become smaller but, because of all these relationships, more complex. Object technology traded one devil for another.
As for quality, an improvement is hard to prove. The many GoTo branches are gone, but that isn’t clearly an achievement of object technology; structured programming did that. The cohesion of modules, meaning how closely their internal functions belong together, has increased. So has coupling, the dependency of internal functions on external ones. You could say the building blocks have become smaller, but the number of dependencies has grown all the more.
There are high-quality procedural systems, too. So quality isn’t necessarily tied to the programming technique. It comes from using a technique correctly, whether structured or object-oriented. Nothing is worse than object technology applied wrongly because nobody really understood it.
Studies on the Maintainability of Object-Oriented Software
The claim by proponents of object technology that it would reduce maintenance costs by 30 to 50 percent was never confirmed, even though many researchers tried.
One of the first studies was carried out as early as 1993 by Professor Norman Wilde of the University of West Florida. He used a C++ system from Bellcore. His team analyzed and measured the source code with tools, and also interviewed the maintenance staff responsible for the system.
It turned out that some of the much-praised features of OO programming had negative consequences for maintenance, above all inheritance beyond a certain depth. Another problem came from the large number of interactions between methods in different classes. A third problem was caused by dynamic binding with polymorphism. It makes the code more flexible, but also hard to follow. The average developer can’t cope with it and makes wrong decisions when changing the code, which leads to bugs that are hard to find.
On top of that, Bellcore had more bugs to fix in its new object-oriented systems than it had had in the old procedural ones. System performance also dropped: the run times of the new C++ systems rose by 45 percent compared with the old C systems. The study concluded that object orientation brings some advantages but equally serious disadvantages. The decisive factors for the maintainability of OO programs were the depth of the class hierarchy, the number of associations and the use of polymorphic binding. In other words, the more object-oriented the work, the higher the maintenance effort.
Another study on maintainability took place at the University of Wisconsin in 2007. A research team led by Professor Michael Eierman looked into whether object-oriented systems really are easier to maintain. For the comparison, they defined maintenance as an umbrella term for bug fixes, functional enhancements, changes and refactoring. Maintainability was defined as keeping the effort for these activities to a minimum.
The claim under test was that the properties of object-oriented software do more to reduce maintenance effort than those of procedurally developed software. The researchers set up five hypotheses:
- OO systems are easier to understand.
- Maintenance work on OO systems is easier to plan.
- Know-how about OO systems can be built up faster.
- Diagnosing bugs is easier in OO systems.
- Changes to OO systems have a smaller impact.
To find out whether these assumptions hold, Professor Eierman brought 162 advanced students into his experiment. The students had learned both COBOL and Smalltalk. They were asked to fix and change either a COBOL or an object-oriented application: first to fix a bug, then to add an extra calculation to the code. 81 students chose Smalltalk and 81 chose COBOL.
Professor Eierman’s team concluded that there was no significant difference in maintainability between the procedural and the object-oriented solutions. Whatever was gained in one activity was lost in the other. In the end, maintaining the Smalltalk solution even cost 3 percent more. Eierman and Dishaw concluded that OO software is not easier to maintain, at least not according to the results of their study.
One of the authors ran his own comparison of the maintainability of COBOL and Java code at the University of Applied Sciences in Hagenberg. Students there were given the same application (an order processing system in COBOL and in Java) and asked to fix a bug and make a change in both versions.
The bug fix was done fastest in the COBOL code by every team: no team needed more than an hour. The change, on the other hand, went faster in the Java code. Adding a new subclass in Java was easier than rewriting a section of COBOL code. No team needed more than two hours for the Java enhancement. The COBOL change took them considerably longer.
That may be because the students were more familiar with Java. But it also shows how difficult such comparisons are. The people taking part in such studies will always know one technology better than the other. Maintainability is hard to measure because maintenance covers many different activities: fixing bugs, making changes, adding features, optimizing and renovating. What is easy in one programming language is hard in another. In the end, all we can say is that claims about maintainability can’t be verified. Object orientation may lower maintenance costs in the long run, but it is very hard to prove.
Testability of Object-Oriented Software
A large part of maintenance costs comes from testing, and there is no dispute that testing object-oriented systems takes extra effort. Robert Binder, an internationally recognized testing expert and author of several books on testing, argues that OO software is not only harder to test but also produces more defects. Boris Beizer estimates that testing OO software costs four times as much as testing traditional procedural software, and James Martin, the guru of the structured world, saw a huge wave of testing effort rolling toward us with the arrival of object technology.
Why is object-oriented code harder to test? First, heavy modularization leads to more dependencies between modules. Methods in a class under test call methods in other classes, and those in turn call methods in classes even further away. One of the authors of this article tried desperately to simulate all external references of C++ classes so that he could test them. In the end he had to give up, because there was no way to code that many stubs. JUnit runs into the same problem. To test one class, the tester has to include all the other classes involved in the test or simulate them through class flattening. Either way, the tester has more work than if the test object could be tested on its own.
Second, data-centered classes contain methods that are procedurally independent of each other but tangled up through shared data attributes. One method can leave behind an object state that affects the behavior of the methods that follow. The input domain of a method includes not only the parameters passed in from outside but also the internal attributes of the encapsulated object. Their state affects the test, and the tester has to set it up in advance. What matters is testing not only all branches in all methods but also all relevant object states.
Third, when a widely reusable class is developed, nobody knows yet what the method will be used for. It has to be designed to serve any potential purpose. That kind of openness forces a comprehensive test that covers every possible use. Reuse comes at a price.
As early as 1996, Capers Jones examined 600 object-oriented projects in 150 different organizations and came to the following conclusions:
- The number of defects caused by misusing object technology was strikingly high.
- Defects in analysis and architecture had a much greater impact than defects in procedural analysis and design methods.
- Finding the causes of defects took more than twice the effort.
- Defect density is higher because the code is more compact.
- Only where more than 50 percent of the code is reused does the defect rate go down.
It was to be expected that object technology would drive up testing effort. Object-oriented code has many more dependencies and many more possible uses, and testing them all takes more effort. The answer came in the form of test automation. To get the testing problem under control, users had no choice but to automate their tests. You can also see this in a positive light: the high cost of testing object-oriented software made test automation unavoidable.
Goal Three: More Reusability
When it comes to reusing existing software, object technology has undeniable advantages. It made it possible to build general-purpose class libraries that can be handed on from project to project. There are several reports of projects that saved more than 50 percent of the estimated effort by reusing code from earlier projects.
It is questionable, however, whether the same savings wouldn’t have been possible with procedural software. Long before object technology arrived, Capers Jones in the U.S. and Albert Endres in Germany reported successes in reusing code units. General-purpose subroutines, macros and include or copy code sections were already used in the 1970s to save code. Endres also describes other reuse techniques that go beyond code, such as design patterns, application frameworks and standard interfaces. So it would not be correct to claim that reuse is an achievement of object orientation. There is also reuse of processes and functions. Only inheritance directly promotes the reuse of higher-level classes, and inheritance is controversial among experts.
As far as reuse goes, object orientation has helped increase it only to a limited degree. The concept of abstract data types has certainly contributed more. Whether we want to equate that with object orientation is an open question. In the end, we can say that object orientation drives reuse but is not a prerequisite for it. Product line management shows that non-object-oriented software can be reused just as well.
Goal Four: Better Portability
Nobody would deny that object orientation has led to better portability, at least as far as Java is concerned. Encapsulated objects with their standardized interfaces can be moved from one environment to another without much trouble. Unfortunately, components can’t be moved without recompiling them, but the bytecode can be transferred. Either way, portability is much better than with the classic procedural languages, where modules have to be recompiled and relinked.
Today, the ability to move software is a basic requirement for moving local applications to the cloud. The strict division of code into classes, methods and interfaces makes it possible to reuse local classes as global web services. With procedural languages such as COBOL, C and PL/I, that isn’t easily done. One of the authors spent years wrapping such procedural programs as services so they could be reused. That requires building completely new interfaces. With object-oriented code, it’s much simpler.
Critical Voices
There are critical voices on object orientation, too. Victor Basili, professor of computer science at the University of Maryland, raises the question of whether
“Object-oriented is the right way to think in all domains. It is obviously good for some, but we still don’t have enough empirical evidence to support the claim that it is good for all …”
Erik Stensrud, professor at the Norwegian School of Management, ran an experiment comparing productivity in object-oriented projects with productivity in procedural projects. The result was inconclusive. In the end, productivity was about the same. The disadvantages of object orientation cancelled out its advantages.
Professor Thomas Niemann of Portland Community College argues that overusing every feature of object technology can hurt productivity. In his words, “excessive information hiding can be detrimental”, and inheritance and polymorphism make testing harder. If too much information stays hidden, an outsider can’t fix the code. Niemann concludes that productivity is most likely to be achieved with “OO lite”.
Another critical voice on object technology is Professor Manfred Broy. In an article for the German journal Informatik-Spektrum, written together with Johannes Siedersleben, he states (translated from German):
“We argue that object orientation as it is used today does have a whole range of interesting, beneficial properties, but that it also has some serious shortcomings, which show that object orientation is not in line with the current state of scientifically understood programming methodology and software engineering.”
The authors go on to say: “Despite its popularity and widespread use, object orientation does not solve all the old problems by a long shot, and it has created some new ones.” Inheritance and the use of object references in polymorphism cause them particular headaches; object references are nothing more than thinly disguised pointers. The design language UML adds further problems:
- No clear semantics
- Poor integration of the various description techniques
- No component concept
What Broy and Siedersleben criticize most is not so much the OO concepts themselves as the way these concepts are implemented in concrete languages such as C++, Java and, above all, UML.
The missing component concept makes it hard to design a complex architecture. Classes are far too small to serve as the highest level of abstraction. The authors state:
“One of the worst shortcomings of object orientation is the absence of components as a complement to the class. Classes are simply too small, too fine-grained. They are units of implementation, not of construction. Large systems can hardly be structured with them.”
Broy and Siedersleben don’t cite any empirical studies to back up their criticism of object technology, but their wording suggests that object orientation doesn’t change productivity. The positive, productivity-raising effects are balanced out by the negative, productivity-reducing ones. In the end, it comes out at plus or minus zero.
One of the most interesting studies on object technology and productivity was published in 1994 in Communications of the ACM under the title “Requirements Specification: Learning Object, Process and Data Methodologies”. Its authors are Iris Vessey and Sally Conger. The two, a professor and a consultant, studied how well average developers cope with object orientation. Does it really match the way people naturally think? Compared with other development methods, the OO method was the hardest to learn for the people involved. So this approach is anything but the natural way of thinking.
The productivity debate suggests that object orientation does not automatically lead to higher productivity. It depends on who works on the project and how much code gets reused. When experienced developers with solid knowledge of the languages used, UML and Java for example, are at work and more than 50 percent of the code is reused, a significant productivity gain over procedural development can be expected.
If, however, the people on the project have little OO experience and the reuse rate is low, a loss of productivity is more likely. Inexperienced developers combined with a high reuse rate point to unchanged productivity. Experienced developers combined with a low reuse rate point to a small productivity gain (1 to 50 percent). So there is no clear-cut answer to the question of what object technology does for productivity.
Back to the Question: What Has Object-Oriented Technology Delivered?
If we ask, in the end, what the object-oriented movement has brought the software world, we have to subtract quite a bit from the original claims.
Did Object-Oriented Programming Increase Productivity?
In some cases, the effort for software development went down, above all where a high reuse rate was achieved and experienced OO developers were at work. Where little was reused and inexperienced staff were involved, productivity fell. Using object orientation correctly places high demands on developers. If they aren’t up to it, their productivity is limited.
Compared with some fourth-generation languages, Java and C++ do poorly. Only C# with .NET can more or less keep up. While studying productivity at a large Austrian industrial company, one of the authors found that
- productivity with a 4GL language for a system of more than 32,000 function points was two function points per person-day, while
- productivity for a Java application of more than 12,000 function points was only 1.1 function points per person-day.
So raising productivity is not exactly a strength of object technology, especially when inexperienced people are at work.
Does Object Orientation Reduce Maintenance Costs?
There is no empirical evidence that it does. The few studies that exist point to plus or minus zero in maintenance. In some cases, maintainability improved, particularly where the amount of code was reduced significantly and many standard components were used.
In other cases, the software became so complex that the maintenance staff could no longer cope. Maintenance costs went up. Without regular refactoring, complex OO systems in particular spun out of control. With procedural systems, developers could keep things running somehow, even if badly. That is not the case with object orientation.
Has Object Orientation Promoted Reuse?
The answer is a qualified yes. Object-oriented components are usually easier to detach from their environment and easier to encapsulate. That conclusion comes from one of the authors’ experience with reusing classes as web services. On the other hand, there is too little real scientific evidence for the claim. Software was reused extensively before object orientation, too. It’s hard to say how much object orientation has made reuse easier. The most we can say is that a lot speaks in its favor.
Has Object Orientation Improved the Portability of Software?
Of all the claims, this one holds up best. Because the code has standardized interfaces, it can be moved to other environments and made to run with little adaptation. Developers don’t have to rewrite the code. For distributed processing, that is a decisive advantage. The concept of distributed objects fits well with today’s diverse digital world. With portability, object technology set an important course.
Conclusion
Object-oriented technology has fallen well short of everything it originally promised, especially when it comes to productivity and easier maintenance. In return, it has had other positive effects on software development. It promotes reuse and frees software from dependence on a proprietary environment. Object orientation opened up the world of software, and that alone has justified it.
Frequently Asked Questions
Which features of object-oriented programming are intended to make development more productive?
Three mechanisms were highlighted: encapsulation, inheritance, and polymorphism. The encapsulation of data and functions makes it possible to assemble large systems from many small, pre-built building blocks. Inheritance was intended to eliminate redundant coding, which accounted for more than 50 percent of the code in structured programming. Polymorphism replaces rigid module dependencies and simplifies deeply nested switch statements.
Are there types of applications for which object-oriented development is practically the only option?
Yes, particularly graphical user interfaces, telecommunications, and multimedia. Examples cited in 2016 included IBM’s TPF2 timesharing system, written in an object-oriented version of PL/I, as well as Apple’s Lisa and Macintosh. There were also successes in traditional data processing: An automotive supplier achieved a 200 percent increase in productivity using C# and .NET, primarily through the use of pre-built components.
Do systems become more easily maintainable when they are broken down into many small classes?
Not automatically. The building blocks become smaller, but their number increases, and with every inheritance and every association, the number of relationships grows. Complexity is measured precisely by this. Added to this is the dependency among developers: whoever writes an inheriting class depends on the author of the superclass. The systems became smaller, but more complex.
Is there evidence to support the promised reduction in maintenance costs through object-oriented programming?
No. The claim that maintenance costs would drop by 30 to 50 percent has never been confirmed. In 1993, Norman Wilde examined a C++ system developed by Bellcore and found the opposite: deep inheritance hierarchies, numerous interactions between methods of different classes, and dynamic binding made maintenance more difficult. There were more errors to correct, and runtime increased by 45 percent compared to the old C systems.
Why is object-oriented code more difficult to test than procedural code?
Three reasons. First, methods of one class access methods of other classes, so the tester must include or simulate them. Second, a method’s behavior depends not only on its parameters but also on the state of its encapsulated attributes. Third, a reusable class must be tested for every conceivable use case. Boris Beizer estimated the additional effort to be four times greater.
Is reusability an achievement of object-oriented programming?
No, it predates it. Generically usable subroutines, macros, and blocks of copied code were already saving code in the 1970s, and Capers Jones and Albert Endres reported successes even before the advent of object-oriented technology. Object-oriented programming drives reuse, but it is not a prerequisite for it. Product Line Management demonstrates that even non-object-oriented software has high levels of reusability.
What fundamental criticisms exist regarding the implementation of object-oriented concepts?
Manfred Broy and Johannes Siedersleben criticized not so much the concepts themselves as their implementation in C++, Java, and, above all, UML. Their most serious criticism: there is no concept of a component to complement the class. Classes are too fine-grained, they argued: units of implementation, not of construction. Large systems can hardly be structured using them. They also criticized UML for its lack of clear semantics.
Under what conditions does object-oriented programming pay off in terms of productivity?
Two factors are decisive: the experience of those involved and the degree of code reuse. If experienced developers with solid language skills are working on a project and over 50 percent of the code is reused, a significant increase in productivity can be expected. Conversely, with little OO experience and a low reuse rate, there is a risk of a productivity loss. Experienced developers without significant code reuse yield only a 1 to 50 percent gain.
