Object Technology: Has Object-Oriented Programming Delivered?

Goth, Greg. Has Object-Oriented Programming Delivered? IEEE Software 19:5:104-107, Sep/Oct 2002.

Goth argues that using object technology to hide bugs under useless layers of inheritance means it hasn't delivered. Of course, writing spaghetti procedural code means procedural code hasn't delivered. One of the biggest problems of object technology for more than a decade has been disguising C code as C++ objects and calling it object technology.

Basili argues that it is not a clear win because we don't have enough evidence to state that it is the right way to think about design in all cases. Of course, writing a program is not the way to think about solving a problem in most cases. Does that mean that programming has not delivered?

Stensrud thinks it is good for analysis and design but not at the physical level because inheritance breaks encapsulation. This is a real problem that led to the evolution of business objects and enterprise components.

Briand says it is hard to teach newbies OO design, but that the patterns movement has provided sound recipes that have enhanced the programming discipline. It's always been hard to teach good design. Object technology just surfaces a hidden problem that has derailed legions of procedural projects.

Webster puts the blame on C++, a brittle, complex language, that a lot of programmer's have impaled themselves on. Boehm weighs in that encapsulation and information hiding are good things, but C++ wasn't really well designed for this. Good points.

Neiman has written a compelling article on embedded systems that makes the case that procedural code is better. See Embedded Systems Magazine.

Sharma makes the point that focus on the language in not the proper place to evaluate object technology. And maybe that is the most important point.

Object technology pushes the emphasis towards design and that has important implications:

1. It enabled the patterns movement, an excellent vehicle for improving the capability of all programmers.

2. It enabled component engineering which allows teams to work separately on enterprise components in a way that mitigates some of the integration disasters we had with large systems in the past.

3. It enabled smaller teams, set the stage for improvements in productivity which occur inherently in small team size, and provided an environment where agile development was feasible for large projects.

But deeper than this, maybe the most profound impact of object technology has been the ability to refactor systems on the fly (emergent architecture), allowing the evolution of a bad design to a good design, and the ability to enhance the system design during the maintenance process. For indepth analysis of the importance of refactoring, see:

Fowler, Martin et al. Refactoring: Improving the Design of Existing Code. Addison Wesley, 1999.

The impact of the ability to refactoring allowed the essential elements of lean manufacturing to be introduced to software development. Agile approaches to development capitalizes on this by working closely with customers, implementing only those features absolutely essential now, and deferring design decisions and technical implementations to as late as possible, in order to incorporate rapidly changing requirments in real time.

Mary Poppendieck provides an outstanding analysis of how the radical revolution in manufacturing in recent decades in beginning to revolutionize software development. She has published her entire new book online. Highly recommended.

Poppendieck, Mary. Lean Development: A Toolkit for Software Development Managers. Addison Wesley, 2003 (in press).