Object Orientation: The Importance of Being Earnest

Meilir Page-Jones

Several times a week I get an inquiry about the object-oriented courses that we offer. Usually inquirers tell me that their shop is “going object oriented” — or some similar expression. I then ask “why?”

The ensuing conversation goes something like this:

“Why what?”

“Why is your shop adopting object orientation?”

This question is apparently so bizarre that it often engenders total silence. I can imagine people holding the phone away from their face and just staring at it. Eventually, however, I get an answer. Here, summarized or paraphrased, are some of the answers that I’ve received during the past few months:

1. It’s the latest thing, isn’t it?

2. I read about it in Business Week.

3. I think our competitors are using it.

4. My boss’s boss read about it in Business Week.

5. Our programmers are demanding to use C++.

6. C++ is a better C.

7. Structured techniques don’t work.

8. We want increased reusability in our projects.

9. We want to develop an in-house library.

10. Our users want icons and a mouse.

11. We want to use a purchased library.

12. We’re seeking more robust systems.

13. We want to boost the productivity of our programmers.

14. Three of us went to a talk by Bertrand Meyer and we’re really enthused.

Some of these reasons are excellent, some are ridiculous and some are in between. Below, I discuss the proffered reasons one by one.

1. It’s the latest thing, isn’t it?

This answer is the hallmark of a reactive shop, one that leaps at every new technology like a cat leaps at a butterfly each time that it alights. A reactive shop has no direction; or, more precisely, it changes direction with each technology that it embraces.

The consequence is “progress” that resembles a drunkard’s walk. There is much motion in the shop, but very little movement. It’s almost certain that this shop is in what I call the Age of Anarchy. (This is equivalent to the SEI Level 1 Maturity. See Section 2, for example.)

In this shop, object orientation will be the Method of Great Hope for about a year. This will be just long enough for the shop to expend great energy and income on object orientation. But it won’t be long enough for object orientation to yield any rewards of productivity or reliability. So, at that time, the shop will abandon object orientation as a False Promise and will take up with the next fad — Radical On-Going Business Refabrication or whatever.

2. I read about it in Business Week.

3. I think our competitors are using it.

My instant cynical reaction to both these responses is “So what?” I think that object orientation’s appearance on the front cover of Business Week[1] with the heading ”Software Made Simple” was the silliest thing since Dr. Hook appeared on the front cover of Rolling Stone. That one’s competitors are using object orientation is mildly interesting, but not of itself much reason for embracing the technique.

Both the Business Week phenomenon and your competitors’ apparent infusion of object orientation may simply be symptoms of the vast pandemic that object orientation has now become. Do not mindlessly succumb to object-oriented hysteria. Although object orientation has some tremendous benefits, it also has many dangers. Be circumspect in adopting it. At the end of this article I offer some criteria and timing considerations for adopting object orientation.

4. My boss’s boss read about it in Business Week.

This was a particularly funny one, which I didn’t hear over the phone but at a conference cocktail party. Apparently, the boss — call him Nosbert — was Head of Software in a medium-sized company and the boss’s boss — call him Luigi — was Manufacturing Manager in the general corporation and had no real knowledge of software. After reading Business Week on a plane, Luigi called Nosbert into his office.

“Nosbert, are we doing this object-oriented stuff?”

“Er, no.”

“Then get with it. I don’t want our company to miss the bus.”

Nosbert then implemented one of the most painless transitions to object orientation in the history of the universe. He switched his compilers from C to C++ but told his programmers to continue to write C code in the same old way. He then went back to Luigi and was able to report that all his programmers were now using C++ (developed by the very guy who was sitting under the tree in Business Week). Since C++ is an object-oriented language, we must be an object-oriented shop.

Everyone was happy. The programmers barely noticed a difference. Except for a few brave experimentalists, none of them changed coding habits. Nosbert had saved face without having to do anything significant. Luigi could hold his head high now that company was again basking in the white heat of modern technology. I believe that the management term for all of this is “declaring victory.”

5. Our programmers are demanding to use C++.

One person who gave me this answer explained that her programmers felt that, unless they learned C++, they would be cast as dinosaurs and soon fossilized in some forgotten stratum of software engineering.

Another person said that his programmers regarded C++ to be a “politically correct” language. (I still haven’t figured out what that means!)

Yet another respondent characterized C++ as being a “twin-engined jet-propelled language,” in contrast with C or Pascal (which I presume are merely single-engine prop. languages).

These metaphors for C++ baffle me. If I had to come up with an image, I’d say that semantically C is a ramshackle hut and C++ is a two-story ramshackle hut. To me C++ seems to be a language that has sacrificed orthogonality and elegance for random expedience.

Anyway, I believe that C++ is about the worst first object-oriented language for a programmer to learn. To get a thorough grounding in object-oriented programming concepts - as opposed to arbitrary C++ features — a programmer should learn Java, Smalltalk or Eiffel before C++.

I’m not so naïve that I believe C++ will suddenly go away. Like the poor, it will always be with us. However, I believe that a programmer who comes at C++ with a sound mental discipline will be able to mold and subset the language into one that yields code with some semblance of elegance and understandability.

6. C++ is a better C.

Despite what I wrote above, C++ has some features that remedy problems with plain C. Chief among these is the strong type-checking, which C++ has but which C lacks.

I think that it’s perfectly fine for a C shop to migrate to C++ for its “better C” features, rather than for its object-oriented features. And obviously such a migration will not preclude a later incursion into object orientation. Nevertheless, I don’t withdraw what I said above: C++ is not the best language by which to learn the concepts of object orientation. And, of course, if you’re looking for the “C family resemblance,” Java will offer the easier learning curve.

7. Structured techniques don’t work.

The wording of this answer is fascinating, because, as it stands, it’s untrue. Although structured techniques have failed in many shops, they’ve also succeeded in many others. A better wording would be:

“Structured techniques didn’t work in our shop.”

Or, probably even more accurately:

“We were unable to apply structured techniques successfully.”

So now I’ve transformed the original statement:

“Structured techniques don’t work (and so we’re moving on to object-oriented techniques, which presumably do).”

into:

“We were unable to apply structured techniques successfully (and, despite that, we’re going to launch into an even more sophisticated set of techniques).”

My experience has been that the shops which were the most successful with structured techniques are also the most successful with object-oriented techniques. This correlation isn’t strange. Structured techniques are successful only in shops that have direction and foresight, good team communication, discipline and management commitment to up-front analysis and design.

Object-oriented techniques are, in many ways, like structured techniques — only more so. Success in deriving useful classes, sound class hierarchies and other object-oriented structures requires a degree of software-engineering discipline that surprises even some experienced software engineers. Shops that have failed with structured techniques should examine carefully the reasons for their failure — not merely declaring that “structured techniques don’t work” — before adopting any other set of techniques. This is especially important if those techniques are object-oriented.

8. We want increased reusability in our projects.

On the face of it, this answer could hardly be more rational. After all, reusability is the most usually touted reward of using object-oriented techniques. The evidence also shows that this reward can be substantial — more on this later. So, what’s the problem?

The problem is willpower. Is it really true that you want increased reusability in your projects? Is it so true that you’re prepared to make the founding investments (such as those in Section 9, below) that it takes in order to achieve reusability?

Bear in mind that object orientation has a severe ”technology trap” associated with it. (I wrote about this in The seven stages of expertise.) This means that the first project in an organization to use object orientation will likely achieve little productivity gain and will be required to pay a huge initial investment penalty. Specifically, the first object-oriented project will spend a lot on developing a robust library of reusable classes but will itself reap no benefits from reusability. What is there to reuse?

You must consciously choose the goal for your first object-oriented project. Is it to be the time-consuming and expensive construction of a long-term repository of reusable components? Or is it simply to be getting the application-at-hand out the door? If you try to switch between these goals in mid-project, you may well fall between them and achieve neither goal.

So, choose your goal for object orientation, make sufficient investment to realize it and then be earnest about achieving it.

9. We want to develop an in-house library.

My rule of thumb for developing class libraries is that it takes about 20 person-days per class to build for the here-and-now. It takes about 40 person-days per class to build in solid reusability for future projects. This extra effort will go into deeper design, inspections, documentation and so on.

But developing classes for a library, tough though it is, is only half the battle. The library has to be supported and maintained. You will need a librarian (possibly a small team) to maintain the quality of the library and a library consultant (possibly a small team) to assist project teams in their reuse of classes. I think that one library consultant for every four concurrent projects is a minimum.

When you’re considering an in-house library, don’t skimp. Don’t skimp on the development budget, the documentation budget or the maintenance budget. Deterioration will quickly set into the library if you do.

10. Our users want icons and a mouse.

Object orientation has long been associated with icons and mice. There are at least three reasons for this. First, some systems represent an object graphically as an icon, with methods to be applied to that object being selected by a combination of mouse clicks or menu selections. Second, graphical user interfaces can be implemented neatly using object-oriented design and programming. Third, many object-oriented environments are themselves accessed via an icon / mouse graphical interface.

Nevertheless, if you’re about to develop an application to run under (say) Microsoft Windows, you’re not obliged to go whole hog on object-oriented design and programming. Even if you use a vendor-supplied library of Windows utilities, which may well be object-oriented or object-based, you can still usually write your application in C, Pascal or another standard language.

In fact, if your shop is moving to applications with graphical / windowing interfaces for the first time, then you should probably not burden yourselves with a new language too. Delay using (say) C++ or Eiffel until you’ve mastered the novelties of the interface programming. Then you won’t have to confront two significant changes at the same time — and you may have to wait only one project before taking up an object-oriented language fully.^*

*Racko’s Law (from Roland Racko) states: “An organization can handle only 2 plus or minus 1 significant changes simultaneously.” I think that Mr. Racko is an optimist.

11. We want to use a purchased library.

Although, as we saw above, using a purchased object-oriented library may not demand that you use object orientation, in many cases it does. But studying someone else’s library before you undertake developing your own is a good way to start with object orientation.

However, don’t underestimate the cost of becoming familiar with a vendor library. Some simple classes may take only an hour to absorb. But most classes in a typical industrial-strength library with inheritance take a designer about a day per class to learn thoroughly.

Yet, even this seemingly large number is an order of magnitude less than the cost of developing your own classes. (See Section 9, above.) And, of course, developing your own custom library will be a lot smoother if you’ve first mastered the (vendor’s) foundation classes on which you’ll build.

12. We’re seeking more robust systems.

This can be an excellent reason for espousing object orientation. Object-oriented design allows the definition of so-called ”class invariants,” assertions that must be true for all objects of a class (when they are in equilibrium). The Eiffel language makes excellent use of these invariants and other types of assertion. (See Section 3, for instance.) Furthermore, it provides a “rescue” mechanism for graceful recovery should any of these assertions be violated through, say, a programming error.

These assertion / rescue clauses yield systems that, although prone to the construction defects that all software is heir to, do not crash and burn in unpredictable, calamitous ways. This, of course, can be vital in process-control or life-critical systems, for example.

I expect that over the years more and more object-oriented environments will provide assertion and rescue mechanisms that fit so naturally with object orientation. Furthermore, the repeated use of class libraries will render each class very sturdy, as any initial problems are worked out early in its lifetime.

13. We want to boost the productivity of our programmers.

I’ve heard all kinds of numbers for the increase in productivity that object orientation can provide, all the way up to 15:1! My experience — and I admit that there’s not much good data around — is that you can reduce the number of lines of new code for an application by about 5:1. However, this reduction in new code requires the development of a sound in-house library and about 5 years of elapsed time.

But the above ratio calls for a big caveat: System-development cost is not reduced by 5:1. Requirements analysis won’t go away and object orientation imposes such an overhead on writing new code — understanding what can be reused, understanding how to reuse it, extending the library etc. — that the cost of a new application may be reduced by “only” 2:1.

Remember too that if you reduce the programming needs of your shop, you’ll have to find something for your extra programmers to do. See Section 4 for more on this issue.

14. Three of us went to a talk by Bertrand Meyer and we’re really enthused.

Good for you! I’m always inspired by Bertrand’s talks too. But be cautious. Assess where you are now in your shop. What are your shop’s strong points and weak points? Which of your weak points are your greatest priorities for addressing? Look at object orientation’s benefits (reusability or reliability etc.) and its demands (discipline or communication etc.).

If its benefits will bolster your weaknesses and its demands call upon your strengths then object orientation is a very good fit for your shop. If the opposite is true, then success with object orientation may well elude you. In that case, you should shore up your weak points before tackling object orientation (or any other software-engineering technique).

Whenever you decide that you’re ready for object orientation, run an initial pilot project. Run it like a true pilot. Keep a log book of difficulties: why they occurred and how you overcame them. This log book will be a treasure house of education for future object-oriented projects that are expected to deliver applications to users and classes to the library.

Even with the comfort of a pilot project, however, beware of the problems of scale. Remember that human-communication problems will be not be the same when 40 people or 400 people are using object orientation as when 4 people are using it.

Since a shop of over 100 people will need at least 3 years to convert to object orientation, perhaps the inspiration of a Bertrand Meyer will be required to sustain so many people for such a long time!

Summary

So there you have it: 14 ostensible reasons for adopting object orientation — some valid, some bogus. You may have observed that the reasons I considered the most valid were those where a shop had assessed its goals and decided that objects were oriented in the direction of those goals.

As I was writing this article, I received another call. Now we have a 15th reason:

“We’ve just completed an SEI assessment and we’ve come out at the bottom level. We’ve decided that we need to establish methods. We’re going to skip structured techniques, because they’re old-fashioned, and go right into object orientation.”

Exercise for the reader: What do you think of this reason? What are its pros and cons, its benefits and its dangers?

References

[1] Software made simple. Business Week, 30th Sept. 1991, McGraw-Hill.

[2] W.S.Humphrey: Managing the software process. Addison-Wesley, 1989.

[3] B.Meyer: Object-Oriented Software Construction. Prentice Hall, 1997.