Professors Vivek Shah VS01@swt.edu, Marcos Sivitanides MS06@swt.edu, and Roy Martin RM05@swt.edu are members of the Department of CIS & QM, School of Business, Southwest Texas State University San Marcos, Texas.

Introduction

Object Oriented Development (OOD) has been touted as the next great advance in software engineering. It promises to reduce development time, reduce the time and resources required to maintain existing applications, increase code reuse, and provide a competitive advantage to organizations that use it. While the potential benefits and advantages of OOD are real, excessive hype has lead to unrealistic expectations among executives and managers. Even software developers often miss the subtle but profound differences between OOD and classic software development.

Expected Benefits of OOD

Many benefits are cited for OOD, often to an unrealistic degree. Some of these potential benefits are [Adhikari, 1995; Taylor, 1995]:

• Faster Development: OOD has long been touted as leading to faster development. Many of the claims of potentially reduced development time are correct in principle, if a bit overstated.
• Reuse of Previous work: This is the benefit cited most commonly in literature, particularly in business periodicals. OOD produces software modules that can be plugged into one another, which allows creation of new programs. However, such reuse does not come easily. It takes planning and investment.
• Increased Quality: Increases in quality are largely a by-product of this program reuse. If 90% of a new application consists of proven, existing components, then only the remaining 10% of the code has to be tested from scratch. That observation implies an order-of-magnitude reduction in defects.
• Modular Architecture: Object-oriented systems have a natural structure for modular design: objects, subsystems, framework, and so on. Thus, OOD systems are easier to modify. OOD systems can be altered in fundamental ways without ever breaking up since changes are neatly encapsulated. However, nothing in OOD guarantees or requires that the code produced will be modular. The same level of care in design and implementation is required to produce a modular structure in OOD, as it is for any form of software development.
• Client/Server Applications: By their very nature, client/server applications involve transmission of messages back and forth over a network, and the object-message paradigm of OOD meshes well with the physical and conceptual architecture of client/server applications.
• Better Mapping to the Problem Domain: This is a clear winner for OOD, particularly when the project maps to the real world. Whether objects represent customers, machinery, banks, sensors or pieces of paper, they can provide a clean, self-contained implication which fits naturally into human thought processes.

Therefore, OOD offers significant benefits in many domains, but those benefits must be considered realistically. There are many pitfalls that await those who venture into OOD development. These pitfalls threaten to undermine the acceptance and use of object-oriented development before its promise can be achieved. Due to the excitement surrounding OOD, expectations are high and delays and failures, when they come, will have a greater negative impact.

The purpose of this paper is to summarize different types of pitfalls that developers should try to avoid when developing applications in an OOD environment. In addition, suggested approaches to avoid these pitfalls can enable system developers to truly capitalize on the benefits of OOD.

Potential Pitfalls of OOD

When new software development technologies are adopted, it is often the case that, during the early stages of adoption, they are misused, abused or create totally unrealistic expectations. Lack of understanding and unrealistic expectations of new technologies seem to be the common denominators for the delay of their proper use. These types of problems can be avoided or minimized by a clear view of the pitfalls that developers face when adopting new technologies.

Many of the pitfalls described below are common to any software development as they are significant in the context of OOD. Some of the pitfalls are commonly believed to be eliminated by OOD when they are not. Further, they may threaten to derail OOD projects in spite of the benefits of OOD.

The next section of this paper analyzes such potential pitfalls from the viewpoint of the various entities involved in the OOD process and recommends tactics that can help prevent or avoid these problems.

Conceptual Pitfalls

Most conceptual pitfalls have two things in common: confusion about what OOD is and what it entails. There are several reasons for this to occur:

First, project managers and developers may confuse form with substance. When structured development became popular, developers and managers thought that structured development simply meant to eliminate GOTO statements and increase the use of subroutines. These steps helped, but they were just two surface features of deeper and more significant principles. Similarly, some developers and managers today think that OOD simply means defining classes, objects, and methods.

Second, managers and developers may not recognize all the implications of OOD. Managers and developers often assume that using OOD will eliminate various development bottlenecks since promises are made that OOD will reduce the management of complexity and will provide architectural modularity. This different approach to architecture, design and coding may require, or at least may work best with, different management and scheduling techniques.

Third, managers may be tempted to abandon and neglect traditional design and software engineering processes. OOD is often adopted because of its promise of increased productivity and a shortened schedule, so sufficient time is frequently not allowed to make sure that procedures are followed correctly. This may result in missed deadlines, schedule slippage, and project failures.

Fourth, developers may get some education about OOD, but not enough. Reading articles on OOD, or even a book or two or taking a class at a local university may create a false sense of confidence and understanding.

OOD requires more discipline, management and training than classic software development does. In all four of the above areas, time spent at the beginning will save time later. This approach, however, has always been difficult to sell to upper management because they would like to have the product ready in the least amount of time and cost.

Education and experience are keys for the success of any OOD project. A company in which upper management, technical management, and developers all work together - using realistic schedules, with continuous education, and solid engineering techniques - will likely have fewer conceptual problems and gain the most from adopting OOD.

Political Pitfalls

Political pitfalls are perhaps the most deceptive, because they have little to do with skill, technology or the worthwhile nature of the project. These pitfalls have to do with blame, power, control, personalities, favors, tradition, credit and image. Developers are prone to blunder into political pitfalls because developers like to think of themselves as rational technocrats and assume that others will think as they do and be motivated as they are.

At the same time, it is a common mistake for upper management to assume that developers are ignorant about organizational politics [Lucas, 1989]. Development and application end-users resist acceptance of OOD technology for many reasons. They may not understand the technology; they may have strong feelings about the language or tools they are currently using; they may want to adopt object technology but would like to do it their way; and they may have any of many other reasons to resist acceptance of OOD. It is important for the developers to realize that organizational politics exist, are significant, and also can not be ignored.

There are, additionally, two separate but related tasks important in preventing political pitfalls. The first task is the education of management about what OOD entails, which means that developers had better know it themselves, and know it well enough to explain it to non-technical people. The second task is a need for developers to enlist the support of key people: those who can affect budgets and resources, and those who can affect the scope and direction of major projects [Mattison & Sipolt, 1995].

Analysis and Design Pitfalls

Traditional analysis and design efforts in software engineering tend to focus on one of four aspects: functional decomposition, data flow analysis, state-flow analysis, or the events to be handled [Thompson, 1992].

Object-oriented analysis and design goes a long way toward bringing all four aspects together. Since an object contains information and the actions that work on it, developers address problems in terms of process and data simultaneously. State modeling can then be done in terms of the states of each object, with events mapping nicely onto messages and methods. However, this does not make Object Oriented Analysis and Design (OOAD) obvious or simple, even for those with skills in traditional methods.

Developers often carry into OOD a bias toward the traditional system development life cycle (SDLC). Analysis and design pitfalls come from the struggle to manage complexity, while gaining a sense of how object technology works. Two possible situations are related to this pitfall. First, developers may take a SDLC approach to analysis and design and then attempt to implement it using object-oriented techniques. Second, developers may attempt to use an OOAD approach, but then create classes with their hierarchies and connections which is more along the lines of traditional programs. In both cases, there may be a confusion about the relationship between object classes that would result in poor solutions to the problems, loss of benefits of OOD, and disillusionment with OOD [Adhikari, 1995].

The skill of object-oriented programming, much less object-oriented analysis and design, cannot be acquired overnight. Thus, before developers start a project, they must decide whether to use OOD. They have to ensure that OOD is being adopted for the right reasons and have a good understanding of the risks involved.

There is substantial disagreement about the boundary between analysis and design steps in OOD. Regardless, the first step in OOD system analysis and design is to start the design and then look for trends, patterns, and general categories. Next, decide how to break the system down into subsystems based on architectural decisions. System designers should ponder the essence of the object being represented by the class or subsystem and its natural attributes and behaviors; it is important to look for a cohesive purpose when creating subsystems. The next step is to identify concurrency in the problem. Viewing each subsystem within the context of others, clarifies what is missing in the system and what is unnecessary. Next, developers must choose how the information will be shared by multiple users, identify resources that will use them and the mechanisms for controlling access to them [Williams 1995].

This process is an iterative process. OOD system design and analysis is equal to the basic SDLC approach plus high-level strategy decisions. In summary, if a project is going to be developed using OOD, then everyone affected should study object-oriented analysis and design. Developers should proceed slowly and look for ways to simplify and generalize; good object-oriented designs tend to resolve to general principles.

Environment, Language and Tool Pitfalls

Environments, languages, and tools constitute the most controversial area of OOD and are most subject to change as new technologies are developed. The environment comprises the operating systems and application environments in which a given project will run: Windows, OS/2, Unix and others. Languages include the various object-oriented languages used to implement object design: Smalltalk, C++, CLOS, and others. Tools are what developers use to create and test the application: editors, compilers, browsers, source code management systems, computer-aided software engineering (CASE) packages and others [Taylor, 1990].

The boundaries between the three are not always clear. Smalltalk and Eiffel implementations are often a combination of application environment and tools, centered on language [Mattison & Sipolt, 1995]. Integration is an important consideration for selection of languages, tools and environment. There can be incompatibilities between languages and tools.

Selection of the wrong environment, language, or tool can plague the OOD project with constant problems or bugs in the development of applications. There can also be significant problems in development and deployment because the new system may not be compatible with the current environment. Selection of the target environment and language for OOD is perhaps the single greatest pitfall. It is often difficult to have compatible tools across all environments. Language choices and availability can also narrow environment selection or if the system is being developed for a specific environment, the choice of language or tools may be limited. OOD developers also should consider the learning curve for a language; some languages require a longer learning curve than others. A tool that works for a solitary developer writing a small stand-alone application will not necessarily scale to production release of more complex applications. To prevent this pitfall, it is important that developers consider technology, compatibility and economic issues before selection of environment, languages and tools. Further, developers should validate their selection of tools and languages early. They should try out the complete set of tools that they indend to use for production development as early in the system development as possible.

Implementation Pitfalls

Like many other of the pitfalls mentioned previously, this is not unique to OOD. In fact, it is pandemic to software development and has been addressed repeatedly over the past thirty years [Lucas, 1989]. The last decade of tool development, language refinement, system evolution and hardware advances has given software developers the power to build applications quickly. However, many faults and failings of software development come from neglecting other software engineering activities such as comprehensive analysis, design, development scheduling and deliverables, and proper planning for system testing and installation/conversion [Rabin, 1995].

Concepts, tools, languages, and environments give software engineers even greater power of creation due to such common OOD factors as rapid prototyping, code and design reuse, rapid application development, and greater management of complexity. Developers can rapidly add and modify features. However, since it is fast and easy to create an object class or get a basic feature working, one can be fooled into thinking that completion of that task will be just as fast and easy. The real danger is that coding fast appears to work for a while, but often there is little immediate feedback telling engineers that they are on the wrong path. Usually, this leads to the establishment of an inappropriate architecture and feature implementation.

To prevent intensification of this problem in OOD, it is important that analysis and design be sufficiently completed. It is important to define design, implementation, documentation and coding standards for each subsystem and class before coding and implementation take place. This would seem obvious, but it is easily overlooked in the OOD environment.

Class and Object Pitfalls

There are many pitfalls in this category. Each one of the following can lead to poor hierarchy and class design, unpredictable behavior of objects, unnecessary complexity in the project, loss of OOD benefits, low rate of code reuse and product instability [Bosworth, 1992].

• Confusion of is-a, has-a, and is-implemented-using relationships;
• Confusion of interface inheritance with implementation inheritance;
• Use of inheritance to violate encapsulation;
• Use of multiple inheritance (MI) to invert the is-a relationship; and
• Use of Multiple inheritance in any circumstances.

These and similar misuses of inheritance seem to have short-term values, but they usually come back to haunt developers in the end.

To avoid these pitfalls, developers should set guidelines to create class hierarchies. For each class to be defined, use the descriptions to determine the relationships with existing classes. Further, set up the interface and implementation inheritance according to the class design. Also, set guidelines for how methods should be exported and inherited or overridden.

Class and object design is an art and a skill that comes with time, thought, learning, practice and experience. Class and object implementation is a science, based on careful following of canonical forms, coding standards, pre- and postconditions, and other aspects of software engineering. By combining these factors, developers can create classes that are logical, relevant, subclassable, portable, loosely coupled and most importantly reusable. This pitfall is far easier to avoid than to correct.

Reuse Pitfalls

OOD presents a real dilemma since it was first touted for speed of development. It turned out that for first-time projects, OOD was more difficult and took longer, unless developers could use class libraries and other tools that provide for code reuse. So, it seems that reuse is a benefit of OOD, but that the payoff will be in the long run, not the short term.

One of the primary goals of OOD has been reuse of code. However, the explicit goal of reuse is harder and takes longer because reuse takes time and effort up front, whereas OOD is promoted and adopted as a means to get software developed more quickly. Because of that, the initial design effort is neglected, and the result is a lot of work after the fact to massage existing software into a reusable shape. Further, management expects reusable software for subsequent projects. This is seldom the case, because similarities among projects are often small and expectations for reuse may outstrip the skills and experience of the developers involved [Hayes, 1996].

To focus on reuse of code, rather than the design of OOD, usually leads to unnecessary delays and slipped schedules. To avoid this pitfall, developers should plan and design reuse before a single line of code is written. It is also well worth the time and resources necessary to track dependencies and interactions, particularly among objects or subsystems that are expected to be reused. Thus, the reusability of objects must be documented in the design of a system as a fact, instead of as a future potential benefit.

Conclusion

There are many pitfalls and traps involved in using OOD technologies, just like there are in using traditional methodologies for application systems development. However, if OOD is used properly, the rewards and benefits can be greater than using traditional approaches.

While OOD offers significant benefits, it also raises many concerns. How much training is required and what is the expense? Other concerns include the maturity of technology, and related tools, lack of standards, and execution speed. Integrating OOD into the current development methods will require tools that are open and do not include proprietary technology.

Although these concerns are real, and need careful considerations, OOD offers the only realistic solution to the promise of truly distributed client/server applications. As organizations move to OOD, they are facing and resolving problems related to interfacing objects to current technology, training and design methodology issues, and the basic conflicts that developers face when moving away from data independence principles to encapsulation.

Just like the adoption of any new technology, there is a learning curve involved with the adoption of OOD. Instant and complete submersion in OOD can be disastrous, whereas carefully planned and scaled adoption of these new technologies can bring out all the positive advantages that they have to offer. Proper education in the OOD paradigm and technologies must precede any attempt to use OOD. In the beginning, it should be used for small-scale, non-mission critical applications, so that the organization may receive quick feedback and make necessary adjustments in its usage of these new technologies.

It is clear that the OOD paradigm and technologies are with us to stay and will help us create the application systems of the next century. We must continue our pursuit of the enhancement of the tools and our own education in order to gain the maximum benefit from Object-oriented development.

Selected References

Adhikari, Richard. "Adopting OO Languages? Check Your Mindset at the Door," Software Magazine, November 1995, pp. 49-59.

Booch, Grady, Object Solutions: Managing Object-Oriented Project, Addision-Wesely Publishing Company, Menlo Park, CA, 1996.

Bosworth, George. "Objects, not Classes, are the Issues," Object Magazine, November-December, 1992.

Harmon, Paul and David A. Taylor. Objects in Action: Commercial Applications of Object-Oriented Technology, Addision-Wesely Publishing, Reading, MA, 1993.

Hayes, Frank. "The Reality of Object Reuse," Computer World, May 6, 1996, p. 62.

Love, Tom. "Seven Deadly Sins of Object-Oriented Development," Journal of Information Systems Management, Summer 1995, pp. 84-86.

Lucas, Henry. Managing Information Services, McMillan Publishing Company, New York, NY, 1989.

Mattison, Rob & Micheael J. Sipolt. "An Object Lesson in Management," Datamation, July 1, 1995, pp. 51-55.

Parkhill, Dave. "Object-Oriented Technology Transfer: Techniques and Guidelines for a Smooth Transition," Object Magazine, May-June 1992.

Rabin, Steven. "Host Developers to Object Technicians," Information Systems Management, Summer 1995, pp. 30-39.

Robinson, Terri. "To Avoid Pitfalls, Walk Before You Run," Software Magazine, October 1996, pp. S8-S12.

Steger, Hal. "End-user's Dream, an IS manager's Nightmare," Computing Canada, March 1, 1995, p. S34.

Taft, Darryl K. "Object Technology Hits Mainstream Markets," Computer Reseller News, September 4, 1995, p. 85.

Taylor, David A. Object-Oriented Technology: A Manager's Guide, Addision-Wesely, Reading, MA, 1990.

Thompson, Don. Reorganizing MIS: The Evolution of Business Computing in the 1990s, Sams Publishing, Carmel, Indiana, 1992.

Williams John. What Every Manager Must Know to Succeed with Object Technology, SIGS Books, New York, NY, 1995.