MIS, beware OOP's promises - object-oriented programming - Forum

In Michael Bucken's January 1994 editorial, "Objects Create Strange Partners," he states, ". . . few would disagree that [object] technology will one day spread throughout the software development world." I, for one, strongly disagree. I believe that object-oriented programming (OOP) will fail miserably when used to design, develop and maintain mission-critical MIS applications.

Building off-the-shelf software products is significantly different from building mission-critical MIS applications. While some MIS organizations have successfully used OOP in pilot projects, these companies will not duplicate those successes if they use OOP to build major appications. These departments will eventually reject OOP technology for the following reasons:

They will conclude that the technology is too complicated. First, the training required to be proficient in OOP is extensive. Also, building and finding "good" objects that can be used in multiple applications requires extensive analysis. Building objects that provide inheritance, become polymorphic, that can be put into classes, and that are encapsulated is only half the battle. Trying to use these objects as building blocks, and then adding C, C++ or other languages code to complement them could mean that a firm will end up with an application that is inflexible, slow and difficult to maintain.

They will discover that "code reusability" is a myth. While companies may believe that OOP will provide common functions or objects for multiple applications, most of those functions either disappear during the design stage or become subroutines of reentrant code for only one application. Even firms such as John Deere and Ford Motor Co. -- which have been early proponents of OOP and have analyzed large applications -- have concluded that OOP will not produce more reusable code than conventional techniques such as copybooks, stored procedures, subroutines, macros and subprograms.

They will find it infeasible to do enterprise analysis for developing reusable objects. Proponents of OOP believe they can eliminate large amounts of programming through enterprise analysis, because the enterpise analysis team will design "reusable code" in the form of "reusable objects."

Building and defining such objects is not only difficult to do, but most firms have neither the resources nor the expertise to invest in such an undertaking. Even if they decide to do the analysis, they will find it is not always practical to develop reusable objects prior to the detailed design of a particular program within an application.

To complicate matters, performing enterprise analysis for the purpose of building reusable objects would delay the development of any, or all, applications that might benefit from such common objects or functions. Firms are thus faced with a lose-lose situation -- if they do not perform the analysis, they may not end up with reusable objects, and if they take the time to do it, other application development may suffer.

They will soon discover that maintaining applications containing objects is extremely expensive. For OOP to become a reality for an MIS group, the firm would need to establish a central "object development" group dedicated to developing, testing and maintaining objects. Therefore, an application development group using these objects would be dependent on the object development group to make and test changes.

Testing these changed objects in a specific application would be complicated, as the responsibility for the accuracy and integrity of the objects remains with the object development group, while the responsibility for the application remains with the applicaiton development group.

In addition, once the object development group changes an object, all programs that use it must be retested to ensure integrity.

They will not get the productivity benefits they anticipated. OOP proponents espousing the technology's merits do not take into account the disruption tht takes place when a radically new technology replaces an existing one. Companies will see few of the benefits they expected, and may see their application backlog increases rather than decrease because of the extensive training requirements.

This programming technology is no more likely to deliver on its promise than did expert systems, rule-based logic or artificial intelligence. These technologies promised great productivity gains but delivered nothing but disappointment and confusion when applied to mission-critical MIS applications.

They will discover an alternative to OOP -- fourth-generation languages (4GLs). 4GL technology is rock-solid, having matured over a 20-year period. Today's 4GLs satisfy mission-critical appication development needs in client/server, PC, distributed or mainframe-based environments. These 4GLs are full-function, have modern graphical user interfaces (GUIs), generate efficient code and are easy to use and learn. They can be easily adopted by Cobol programmers and have been proven to increase productivity and reduce maintenance costs.

OOP is often promoted as the technology most suited for developing client/server applications. This notion is alos a fallacy. With the movement to open systems, portability and network solutions, MIS faces more complicated application design considerations. Designers must decide where to place functional code and logic, how to interface to multiple operating systems, whether to distribute databases, and whether to use a transaction processing monitor. Faced with these decisions, the smart firm will look to the latest generation 4GL or other high-level languages for its development needs.

There is no question that organizations need software development tools that keep pace with today's development environments. These tools are available and do not require an object orientation. OOP as a technology is not for MIS organizations. Embrace it, and you -- or your successors -- will live to regret it.

COPYRIGHT 1994 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group