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?