Communications of the ACM
Home/Magazine Archive/October 2000 (Vol. 43, No. 10)/The -Ups and Downs of Object-Oriented Systems Development/Full Text
Communications of the ACM
The -Ups and Downs of Object-Oriented Systems Development
By all appearances, object-oriented systems development (OOSD) is in the throes of a dilemma. Dozens of well-known experts claim the advantages of OOSD make it vastly superior to conventional systems development. But some of them also point to OOSD's disadvantages and question whether it will ever be a dominant approach to systems development. To address this controversy, I conducted an Internet survey of 150 seasoned developers from across the U.S., most with practical experience in OOSD. The results continue to suggest that both OO and non-OO developers view OOSD as superior, that OO developers hold this view more strongly than non-OO developers, and that all developers view the reported disadvantages of OOSD as virtually nonexistent.
Many well-known software development practitioners [2, 3, 7, 11] are convinced that OOSD delivers distinct advantages over conventional systems development, including easier modeling, more code and model reuse, better system quality, and easier maintenance. OOSD is viewed so highly, it has evolved into what is defined by Ivar Jacobson, Grady Booch, and James Rumbaugh as the "unified software development process" [7]. However, some authors continue to warn about the complexity and immaturity of OOSD [6], and others have gone so far as to say that OOSD is simply "long on hype and short on results" [12]. These apparently contradictory views may be a serious concern to managers and developers considering large-scale adoption of OOSD.
While opinions concerning the benefits of OOSD abound in the OO literature, there is little empirical proof of its superiority. Research on OOSD advantages is, at best, scarce and sketchy [1]. Hard-core empirical evidence from the best sourcesexperienced developersis virtually nonexistent. It was this need for data that prompted me to conduct the survey (see the sidebar "How the Survey Was Done").
I compared two groups of developers: those with experience using OOSD in real-world projects (I label OO developers) and those without such experience (I label non-OO developers). The non-OO developers can be divided further into those with training in OOSD and those without such training. As I began the data analysis, I found no significant differences in beliefs about OOSD between the two groups of non-OO developers. Therefore, I treat these groupstrained and untrained non-OO developersas one, for the purposes of the survey.
Table 1 summarizes selected demographic data for the surveyed OO and non-OO developers. Not surprisingly, the groups are quite similar, with the exception of the amount of their OOSD training, OOSD experience, and anticipated future use of OOSD.
I took great care to compare a number of demographic variables for the respondentsincluding age, education, experience, company size, job function, and OO useagainst those of the subscribers to Communications. I found no significant differences (at the alpha=0.05 level) for any of the variables, indicating an absence of sampling bias.
Tables 2 and 3 list the median belief strengths of both the OO and the non-OO developers in OOSD advantages and OOSD disadvantages, respectively. In order to perform an appropriate statistical analysis of the data, I used the median belief strengths. I sorted the statements in the tables by the more precise mean belief strength of OO-developers to establish a priority ranking of importance. The shaded areas in both tables indicate the differences in median belief strengths for OO and non-OO developers are statistically significant (at the alpha=0.05 level).
What non-OO developers believe about OOSD advantages. The data in Table 2 provides many insights into the beliefs of developers concerning OOSD advantages. I focus first on the beliefs of the non-OO developers, most of which are "fairly strong." This result is not surprising, given the predominantly positive attitude toward OOSD in the OO literature. However, non-OO developers do not feel as strongly about certain other possible OOSD advantages, including more understandable application and development models (item 5); improved productivity (item 11); greater user satisfaction with OO systems (item 13); and better communication with users (item 14). Non-OO developers may find OO analysis and design somewhat difficult to understand due to the radical paradigm shift involved with object orientation [6]. They also may believe the process of learning and using the new paradigm can hurt their productivity, at least initially. Finally, non-OO developers do not view OOSD as an important issue with users, perhaps due to the possibility that users generally do not care how systems are developed (OO vs. conventional) and may not need to communicate with analysts beyond a general, verbal description of system requirements.
What OO developers believe about OOSD advantages. Again from Table 2, you can see that OO developers agree quite strongly about the advantages of OOSD, represented by items 19. These advantages involve modeling, modularity, maintenance, system quality, design stability, development flexibility, phase transition, and code reuse. The modeling advantages of OOSD are among the most frequently cited in the OO literature. Improved modularity via objects is the essence of OOSD and therefore should have direct links to maintainability, quality, stability, flexibility, and reuse of the application. These key beliefs about OOSD are substantiated by the survey results.
The next four advantages (items 1013), including the critical one of improved productivity, are viewed only as "fairly strong" by OO developers. Productivity may suffer if developers are still climbing the OO learning curve. Productivity may also depend heavily on reuse (both code and model), which in turn depends on the successful creation or application of class libraries, frameworks, and design patterns. Reuse is also influenced as much by management issues as by technical issues [9]. These elements may still need more time to mature.
OO developers expect improved communication with other developers, more model reuse, and greater user satisfaction, although only "fairly strongly." However, OO developers, like their conventional-development counterparts, do not expect OOSD to result in improved communication with users, again because users may not be involved beyond initial requirements determination.
Differences between OO and non-OO developers on OOSD advantages. The shaded items in Table 2 indicate the median belief strengths of OO developers are significantly stronger (at the alpha=0.05 level) than for non-OO developers. The fact that OO developers hold significantly stronger beliefs for 10 of the 14 advantages generally strengthens the case for OOSD. This result may imply that actual experience with OOSD reinforces early expectations. One must also consider the possibility that OO developers give higher ratings than non-OO developers due to a "halo effect," or the general belief that everything about OOSD is better than conventional systems development. While this interpretation is plausible, not all OOSD advantages, including one of the most highly toutedcode reusedid, in fact, receive significantly higher ratings in the survey. The most important OOSD advantages that really do appear to be strengthened by experience include modeling (items 1 and 5), maintainability (item 3), quality (item 4), and productivity (item 11).
A look at OOSD advantages not held more strongly by OO developers is even more interesting. It is curious that many years of OO experience have not resulted in particular beliefs being held significantly more strongly, including those for improved design stability (item 6), more effective code and model reuse (items 9 and 12), and improved communication with users (item 14). Explanations include the possibility that design stability is more a function of the quality of initial requirements determination or of the frequency of system enhancements than of the type (OO vs. conventional) of the development methodology being used. All else being equal, OO designs may indeed prove more stable over time. Possible problems with code and model reuse (such as learning curve and management issues) and a lack of user involvement in the details of OO analysis and design may explain why the beliefs of OO developers are not stronger in these areas.
What non-OO developers believe about OOSD disadvantages. Table 3 details results about the disadvantages of OOSD. Again, I focus first on the median belief strengths of non-OO developers. Only three of the disadvantages (items 13) are viewed as "fairly strong" by non-OO developers, including two frequently cited in the OO literaturedecreased run-time performance and increased development timeand one involving OOSD's relative immaturitythe lack of availability of adequate OO database management systems. The maturity issue is also frequently cited in the OO literature [5].
Non-OO developers strongly disagree with statements in items 9, 12, and 14, or incompatibility, programming difficulty, and unsuitability, respectively. This disagreement implies that non-OO developers view OOSD as "fairly compatible" with their existing systems development processes, that OO programming is relatively easy, and that OOSD is suitable for their projects. Finally, non-OO developers do not view any of the eight remaining items in Table 3 as disadvantages; most notable are the complexity and difficulty of OO application development and OO programming. The issues of OOSD complexity and difficulty are among the most prominently covered in the OO literature; therefore, it is quite surprising that non-OO developers view them as non-issues. These results may imply that non-OO developers are thinking critically and independently about OOSD. Overall, these findings could be viewed as an encouraging sign for OOSD.
Surprisingly, non-OO developers did not believe in many of the reported disadvantages of OOSD, including its presumed complexity.
What OO developers believe about OOSD disadvantages. Perhaps the most striking result in Table 3 is that OO developers view none of the reported disadvantages as valid disadvantages of OOSD. OO developers essentially ignore items 18, even complexity and immaturity. Even more surprising are items 913, indicating that OO developers believe "fairly strongly" that OOSD is not difficult to learn or apply, is compatible with existing processes, and has demonstrable benefits. Moreover, OO developers believe "very strongly" that OOSD is indeed suitable for their projects (item 14). This result is especially important, as it comes from developers with years of experience with OOSD in real-world projects.
Differences between OO and non-OO developers on OOSD disadvantages. The shaded items in Table 3 indicate where OO developers hold significantly stronger beliefs about OOSD disadvantages than do non-OO developers. OO developers believe more strongly that learning OO application development is not difficult (item 11), that learning and using OO programming is not difficult (items 12 and 13), that the benefits of OOSD can be demonstrated (item 10), and that OOSD is suitable for their projects (item 14).
There are many plausible explanations for these findings. With regard to the difficulty of learning and using OO, experienced OO developers may have become so familiar with OO analysis, design, and programming they have forgotten any initial difficulty they might have encountered getting acquainted with object orientation. Moreover, as they have become more skillful through experience, OOSD may now seem relatively easy. If this is the case, the implication is that experience overcomes initial difficulty. Alternatively, the OO developers may be more innately innovative, and hence more motivated, to learn and use OOSD, and thus more apt to overlook or overcome difficulty. Another explanation is that OO developers are simply in an environment that is much more conducive to or supportive of OOSD (such as the availability of better training programs), making learning easier.
The most comprehensive explanation could be a combination of both. Regardless, there are two main lessons for software development management: select the best and most motivated developers for OO training, and support OO developers through quality training, mentoring, and tools.
Diffusion of innovations theory [10] suggests that a new process, such as OOSD, needs demonstrable results and prove its suitability for existing projects before it can gain acceptance. Therefore, it is not surprising that developers who have completed successful OOSD projects hold more optimistic beliefs in these areas, especially given their overwhelmingly positive views on the advantages of OOSD, as in Table 2.
Conclusions
The survey I conducted of 150 randomly selected systems developers from across the U.S. revealed that OOSD is alive and well. At the time it was done, non-OO developers had already developed a fairly positive view of OOSD through exposure to the OO literature and OO training, as shown by their fairly strong beliefs in most of the reported advantages of OOSD. Surprisingly, however, non-OO developers did not believe in many of the reported disadvantages of OOSD, including its presumed complexity. Still, non-OO developers were fairly concerned about performance and development time issues, as well as the lack of availability of adequate OO database management systems. Such problems should begin to dissipate with time, as object technology matures.
Developers experienced using OOSD in real-world projects hold very strong beliefs as to nearly all the OOSD advantages; these beliefs are usually stronger than those of non-OO developers. In the areas about which non-OO developers report concern, OO developers seem to have none. One of the most surprising findings is that OO developers are not more convinced of the advantages of code and model reuse. Equally surprising, OO developers view OOSD as less difficult to learn and use than conventional methods. The overall conclusion I take from these findings is that the hype surrounding OOSD looks more like reality and that adopting OOSD may indeed be worth the related time, effort, and cost.
References
1. Briand, L., Arisholm, E., Counsell, S., Houdek, F., and Thevenod-Fosse, P. Empirical studies of object-oriented artifacts, methods, and processes: State of the art and future directions. Emp. Software Eng.: Int. J. 4, 4 (Dec. 1999), 387404.
2. Booch, G. Object-Oriented Analysis and Design with Applications, 2nd Ed. Benjamin/Cummings, Redwood City, Calif., 1994.
3. Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes, F., and Jeremaes, P. Object-Oriented Development: The Fusion Method. Prentice-Hall, Englewood Cliffs, N.J., 1994.
4. Davis, F., Bagozzi, R., and Warshaw, P. User acceptance of computer technology: A comparison of two theoretical models. Mgt. Sci. 35, 8 (Aug. 1989), 9821003.
5. Fichman, R. and Kemerer, C. Adoption of software engineering process innovations: The case of object orientation. Sloan Mgt. Rev. 34, 2 (winter 1993), 722.
6. Fichman, R. and Kemerer, C. Object-oriented and conventional analysis and design methodologies: Comparison and critique. IEEE Comput. 25, 10 (Oct. 1992), 2239.
7. Jacobson, I., Booch, G., and Rumbaugh, J. The Unified Software Development Process. Addison-Wesley, Reading, Mass., 1999.
8. Jacobson, I., Christerson, M., Jonsson, P., and Overgaard, G. Object-Oriented Software Engineering: A Use Case Driven Approach, 2nd Ed. Addison-Wesley, Wokingham, England, 1995.
9. Pancake, C. The promise and the cost of object technology: A five-year forecast. Commun. ACM 38, 10 (Oct. 1995), 3349.
10. Rogers, E. Diffusion of Innovations, 4th Ed. The Free Press, New York, 1995.
11. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, N.J., 1991.
12. Smith, H. and McKeen, J. Object-oriented technology: Getting beyond the hype. Database Adv. Infor. Syst. 27, 2 (spring 1996), 2029.
Tables
Table 1. Selected demographic data for surveyed OO and non-OO developers.
Sidebar: How the Survey Was Done
I used three distinct sources to develop my Internet survey's comprehensive list of advantages and disadvantages of OOSD. First, I reviewed the extensive OO systems development literature to obtain expert opinion. I then asked 40 experienced OO developers to tell me the three most important advantages and disadvantages of OOSD via the survey. Finally, I reviewed the OO systems development literature on diffusion of innovations theory [10]. The result was a set of 14 advantages and 14 disadvantages of OOSD, as listed in Tables 2 and 3.
In order to identify and enlist experienced developers, I compiled a mailing list of potential respondents from three sources: U.S. subscribers to Communications (who also belong to software engineering, programming, and MIS special interest groups); U.S. subscribers to OOPS Messenger; and registrants at recent OOPSLA conferences (with U.S. addresses). I then mailed the survey instrument (with cover letter), with the 14 advantages and 14 disadvantages of OOSD and several demographic items (including level of conventional systems development and OOSD experience). The survey asked developers to rate statements about the possible advantages and disadvantages of OOSD on a seven-point Likert-type scale ranging from 1=Extremely Strong Disagreement to 7=Extremely Strong Agreement.
Caveats
The research represented by the survey is by no means flawless. The survey method was at best capable of capturing only self-reported perceptions. It may be more desirable to perform highly controlled laboratory experiments to investigate the ease of OO modeling, the amount of code and model reuse, the quality of completed systems, the productivity of developers, the difficulty of OOSD, and the suitability of OOSD to development projects. However, it is virtually impossible for IT researchers to develop reliable metrics and apply them in a wide range of real-world environments to an equally wide range of advantages/disadvantages. In order to provide a broad-brush view of the state of OOSD, one must sometimes trust the perceptions of front-line developers. After all, social psychologists and IT researchers generally agree that perception is an extremely important subject of study [4].
It could be argued that those with more favorable opinions about OOSD were more likely to respond to the survey, thus biasing the results. While this is a possibility, I took great care in the survey's wording and instructions to avoid bias for or against OOSD. Also, I found no response bias in the sample, compared to the population, for many important demographic variables, including use of OO. To the contrary, it could be argued that those with negative views about OOSD would be just as motivated, if not more so, to complete the survey and return it to me.
©2000 ACM 0002-0782/00/1000 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.
No entries found