Object Orientation: Making the Transition

Meilir Page-Jones

Abstract
1. Legitimate reasons for adopting object orientation: 1.1 Greater productivity; 1.2 Higher-quality systems; 1.3 Higher-quality development process; 1.4 Capacity to build larger systems
2. Why some managers really want to adopt object orientation: 2.1 It’s the latest thing, isn’t it?; 2.2 I read about it in Business Week; 2.3 My boss’s boss read about it in Business Week; 2.4 I think our competitors are using it; 2.5 Our programmers want C++ on their resumes; 2.6 Three of us went to a talk by Bertrand Meyer and we’re really enthused; 2.7 Structured techniques don’t work; 2.8 C++ is a better C; 2.9 We want to use a purchased library; 2.10 Our new development tool forces us into object orientation
3. The basic pitfalls of adopting object orientation: 3.1 “The Fad of the Year”; 3.2 Unrealistic management expectations; 3.3 Training; 3.4 Shop maturity; 3.5 Imperfections and confusion in the current object-oriented world
4. The library: 4.1 Developing the library; 4.2 Caring for and feeding the library
5. Culture: 5.1 Culture and reusability; 5.2 Culture and organization; 5.3 Culture and projects
Appendix A: The five ages of sophistication
Appendix B: The seven stages of expertise

Abstract

Many shops around the world are now contemplating the move to object orientation for their programming, design and analysis activities. Unfortunately, object orientation, though a valuable and sophisticated approach to constructing software, has been over-marketed by unscrupulous vendors. Worse, in some shops the term “object orientation” has become little more than a mantra, chanted by gullible managers who mindlessly seek instant salvation from the software woes around them.

But what are the realities behind a serious transition to object orientation? What are legitimate reasons for contemplating such a move? What are the typical pitfalls? What can sincere managers do to enhance their chances of a favorable outcome to their endeavor?

Section 1 of this paper reviews the well-known bona fide reasons for adopting object orientation. Section 2 lists and explains some not-so-fine reasons for a potential move to object orientation, which unfortunately form a hidden agenda for some imprudent managers. Section 3 examines some pitfalls that lie in the path of any shop — even a circumspect one — moving to object orientation.

Section 4 explores the problems of introducing and maintaining a class library to reap the rewards of reusability. Section 5 looks at the cultural changes that affect a shop as it moves to object orientation. Finally, Section 6 summarizes the dos and don’ts of making a successful move to object orientation.

1. Legitimate reasons for adopting object orientation

In this section, I set the object-oriented approach in context by reviewing its oft-touted advantages. Of course, a given object-oriented project — or even a whole shop — may not reap all of these benefits to the full. But, conversely, a project would be singularly unlucky to miss out on all of object orientation’s advantages.

1.1 Greater productivity

Probably the largest banner carried by the object-oriented army displays the word “reusability.” The idea here, of course, is that rather than our endlessly rewriting the same pieces of code (stacks, drivers, etc.), we should write a piece of code once, keep it in a library and reuse it whenever we can. Clearly (in theory, at least) this is a powerful way to increase programmer productivity. (I discuss the practice of reusability in Sections 4 and 5.)

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 the data, where it exists, is very variable — 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 work.

The above ratio calls for a big caveat: System-development cost is not reduced by 5:1. For example, let me summarize some numbers from a shop that has over a dozen object-oriented projects under its belt.

An application that used to take the shop 100,000 lines of new code to develop now takes only 20,000 lines of new code. However, each of those 20,000 lines costs twice as much to produce as it would have under traditional techniques. The reasons are that requirements analysis won’t go away and object orientation imposes an overhead on writing new code. (This overhead includes understanding which classes can be reused, understanding how to reuse them, extending the library and so on.)

Nevertheless, the shop is still ahead. A system that used to cost 100 beans to develop now costs only 40 beans to develop. In other words, the cost of a new application is reduced by at least 2:1. But remember that if you reduce the programming demands on your shop, then you’ll have to find something for your extra programmers to do. (I return to this topic in Section 5.)

1.2 Higher-quality systems

At various times, and to various degrees, people have claimed that object orientation yields higher-quality systems than traditional approaches do. Typical improvements that people cite are increased system robustness, reliability, extensibility, maintainability and usability.

Although there isn’t space here to delve into all the issues of the qualities of object-oriented systems, I believe that these claims to improved quality are indeed rooted in truth. For example, 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, [Meyer, 1992], for example.) 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 robustness is vital in process-control or life-critical systems, among many others.

I expect that over the years more and more object-oriented environments will provide some form of assertion/rescue mechanism, because this mechanism fits so naturally with object orientation. Furthermore, the repeated use of classes from libraries will render each class very sturdy, as any initial problems become worked out early in each class’s lifetime.

1.3 Higher-quality development process

Not only can object orientation improve the quality of the end-product — the system itself — but it can also improve the quality of the development process by which we create systems. For example, we’ve known for some time that structured analysis is not perfect. Structured analysis contains an historical schism between modelling process and modelling data that was never quite healed. Introducing some object-oriented ideas early in the system lifecycle may therefore improve the quality of the analysis model.

Nowadays, there’s no lack of methods for object-oriented development; today’s problem is the overwhelming proliferation of object-oriented development methods. These methods range from radically object oriented to barely object oriented, from design-only to multi-phase, from novel to venerable, from deeply thought-out to superficial, and from useful to useless. This proliferation, of itself, prevents many a shop from adopting object orientation, simply because the shop is unsure which of the hundred methods is best.

Nevertheless, a shake-out is already well under way in the object-oriented methods field. And, for some shops, even a middle-of-the-road method represents a quality improvement over their erstwhile software practices. This is good news on an unexpected front, because by improving the quality of its development process a shop also boosts its productivity of development. The reason for the boost is that increasing the quality of deliverables in Phase N of a project increases productivity in Phase N+1. Thus many shops can add this productivity advantage to the more popular and obvious productivity slogan of “reusability.”

1.4 Capacity to build larger systems

For a given language, the larger a system, the more lines of code it contains. The more lines of code the system contains, the longer it takes to build, to test and to fix. Of course that’s an over-simplification. Nevertheless, by using suitable higher-level languages to tackle system construction, you can normally eliminate some back-end development problems.

A library of object-oriented classes constitutes a set of high-level “language statements” tailored towards the types of application that your shop normally undertakes. For example, a feature, method or member-function add_part might be equivalent to 30 or 40 procedural-language statements. (This is analogous to the fact that in Pascal, say, an assignment statement might be equivalent to 3 or 4 assembler instructions.)

This is an important reason that a shop using object orientation may have a greater chance of success in building larger systems. In an implementation sense, object orientation “raises the level of the playing field.”

2. Why some managers really want to adopt object orientation

In Section 1, following the lead of most books, journals and conferences on object orientation, I extolled the tremendous merits of object orientation. These merits underlie the justifications that most managers announce (explicitly and in public, at least) for their contemplating the move to object orientation. In other words, reusability, robustness and so forth are the politically correct reasons for moving to object orientation.

But now, as they say, for something completely different. In this section, I investigate several other reasons — ranging from the ridiculous to the defensible — for adopting object orientation, which I’ve discovered through a bit of subterfuge. Several times a week I get an inquiry about the object-oriented courses that we (Wayland Systems) 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 (apart from the standard, politically correct ones) that I’ve received during the past few years:

It’s the latest thing, isn’t it?
I read about it in Business Week.
My boss’s boss read about it in Business Week.
I think our competitors are using it.
Our programmers want C++ on their resumes.
Three of us went to a talk by Bertrand Meyer and we’re really enthused.
Structured techniques don’t work.
C++ is a better C.
We want to use a purchased library.
Our new development tool forces us into it.

The following subsections explore the proffered reasons one by one.

2.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 it alights. A reactive shop has no direction; or, more precisely, it changes direction with each technology 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. (See Section 3.4 and Appendix A.)

In such a 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 Yet Another False Promise and will take up with the next fad — Canonical Relational On-Going Business Refabrication or whatever.

2.2 I read about it in Business Week

My instant cynical reaction to this response is “Big deal!” I think that object orientation’s appearance on the front cover of [Business Week, 1991] with the heading “Software Made Simple” was the silliest thing since Dr. Hook appeared on the front cover of Rolling Stone.

The Business Week phenomenon may simply be a symptom of the vast pandemic that object orientation has become. Don’t fall mindlessly into the object-oriented hysteria. Although object orientation has some tremendous benefits, it also has many dangers. (I outline some of these in Section 3.)

Keep your eyes open and your brains in the ON position as you cross over to object orientation.

2.3 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. 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). C++ is an object-oriented language; ergo, 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-school term for all of this is “declaring victory.”

2.4 I think our competitors are using it

Your competitors’ apparent infusion of object orientation is interesting, especially if your company’s business is selling software. However, it’s not of itself a conclusive reason that you should embrace the technique. Will your shop’s problems be solved by a move to object orientation? Or will they be made worse? For example, will anarchy in your shop both prevent your reaping the benefits of reusability and be exacerbated by the tough changes required by object orientation?

Nevertheless, your competitors’ choice of object orientation is without doubt a wake-up call for your shop. You may have already missed out on the dawn chorus of a novel software technique, but it may well be time to lumber out and greet the new day before the sun is high in the sky and all the best places are taken.

2.5 Our programmers want C++ on their resumes

One person who gave me this answer explained that her programmers felt that if they didn’t learn C++ they would suffer a dinosaurial fate and soon become fossilized in some forgotten stratum of software engineering. 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). This metaphor for C++ baffles 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++ syntax — a programmer should learn Smalltalk and Eiffel before C++. (Or substitute your favorite elegant language(s) for Smalltalk or Eiffel.)

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.

2.6 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 should you address first?

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.

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

2.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 that were the most successful with structured techniques are also the ones 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 — and not merely declare that “structured techniques don’t work” — before adopting some other set of techniques. This is especially important if those techniques are object-oriented.

The above reasons (2.1 to 2.7) lie somewhere between dubious and questionable in their relevance. The following reasons (2.8 to 2.10), however, are much more justifiable as motivators for a shop’s move to object orientation.

2.8 C++ is a better C

Despite what I wrote earlier, C++ has some features that correct problems with plain old 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. Neither, in my humble opinion, is it the best language with which to develop modern systems. Indeed, C++ has many of the characteristics of an object-oriented assembler language.

2.9 We want to use a purchased library

Although using a purchased object-oriented library may not require that you use object orientation, in many cases it does. And studying someone else’s library before you develop your own is a good way to begin 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 may take a designer up to a day per class to learn thoroughly.

Yet, even this large learning cost is an order of magnitude less than the cost of developing your own classes. Furthermore, 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. (More on this in Section 4.)

2.10 Our new development tool forces us into object orientation

Recently, the marketplace has brought forth several development tools aimed at facilitating the construction of so-called client/server systems. (Typically, a client/server system is a distributed system with a graphical user interface.) Most of these tools are based in some way on object-oriented concepts for two straightforward reasons: First, a window is a natural object, since it sends and receives messages and retains state. Second, an object, with its identity independent of its state, is also a natural mechanism for implementing distributed software.

Thus, many shops are pulled into object orientation because of the kind of modern system that they need to develop and thence because of the tools that support such development. Nevertheless, however powerful its application, object orientation remains a difficult software technique. Shops wanting to develop client/server systems using modern object-oriented tools shouldn’t be lulled by vendors’ simplistic siren calls on to the rocks of a quick and dirty, poorly thought-through migration strategy.

Indeed, although you may be about to develop an application to run under (say) 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 that’s object-oriented or object-based, you may still be able to write much of your application in C, Pascal or another non-object-oriented language.

3. The basic pitfalls of adopting object orientation

Any move to a new technology has its pitfalls; a move to object orientation is no exception. In Section 3, I cover several of these pitfalls, some of which apply to technology change in general, while others are specific to object orientation.

3.1 “The Fad of the Year”

You’d think we’d have learned by now. But no; our industry is still subject to “The Fad of the Year” phenomenon. Pick a year — any year. Chances are that that year had a fantastic “new” software methodology, technique, tool or language that was about to eliminate 99.44% of the chronic problems of the industry. Had you picked up a popular trade magazine during that year you would have read many column-furlongs of exhortative prose calling managers to adopt such-and-such a technique before they were cast into an evolutionary cul-de-sac by their fitter and more opportunistic competitors.

There have been many examples of “The Fad of the Year.” For instance, in 1984 The Fad was “relational stuff”; in 1986, artificial intelligence; in 1988, CASE tools; and in 1989 repositories. Throughout the 1990s it’s been object orientation, a veritable “Fad of the Decade.”

Some managers become so obsessed with the reigning fad’s enticing promise of a technological quick-fix to profound problems that they succumb to “Das Wunderwaffensyndrom” (“The Miracle Weapon Syndrome”), as it’s termed by distinguished Viennese psychologists. (This delusion is also known as The “Silver Bullet Syndrome” , and, among eminent South Pacific anthropologists, as “The Name Magic Syndrome” or “Cargo-Cult Methodolatry.” )

Typically, there’s nothing much wrong with the unfortunate techniques that get catapulted into the “Fad of the Year” slot. Indeed, history shows that most fads are actually based on very legitimate technology. However, each technique that has this glory thrust upon it suffers a nasty distortion in its natural adoption curve. Figure 1 shows the natural adoption, or penetration, curve for a typical technology.

Figure 1: The natural adoption curve for a typical technology

Initially, the technology lives only in the labs of a few companies. (This part of the curve is marked “A” in Fig 1.) Some time later, it reaches commercial maturity and its adoption (if it’s any good) takes off rapidly ( “B” ). Eventually, it reaches its limit of useful application and its adoption levels off ( “C” ). (The horizontal time-scale is of the order of one or two decades even in this fast-moving business.)

Figure 2 shows the adoption curve for a technology that becomes “Fad of the Year.”

Figure 2: The distorted adoption curve for a “Fad of the Year”

The first distortion (marked “B1” ) is obvious; it’s the direct “Fad of the Year” bandwagon effect as everyone scrambles willy-nilly to adopt the wonder technology. However, the second distortion (marked “B2”) is unexpected. It represents a mass de-bandwagoning, wherein the population who made up the bubble marked “B1” hysterically desert the erstwhile “Fad of the Year” in a big way, dragging many other - more levelheaded — participants off the cart with them.

In less abstract terms, what happens at “B2” is that the former column-furlongs that eulogized The Fad in trade magazines get replaced by column-furlongs of angry letters screaming that “We tried The Fad and it didn’t work.” This of course not only rapidly deflates the bubble but also puts off potential serious adopters.

In time, the technology will more or less recover from having been a Fad as the more mature and circumspect shops persevere with its use. (I’ve marked this part of the curve by “B3” .)

So what does this all mean for object orientation? Since object orientation has been a Superfad through the 1990s, we can review what’s happened since 1990 and also make some predictions about what might happen during the rest of the decade.

The newsprint devoted to object orientation has increased dramatically in the past few years in journals ranging from Byte to Computerworld. There have even arisen entire publications dedicated to object orientation. Neither has there been a dearth of conferences on object orientation. Indeed I’m alarmed that since there are fewer than 3000 common words in the English language containing “OO” these conferences are in grave danger of running out of names for themselves!

3.2 Unrealistic management expectations

Object orientation is particularly susceptible to the “Fad of the Year” crash, because plenty of managers, egged on by vendors, have been stricken by the Miracle Weapon Syndrome and demand that this new technology yield instant results.

But, ironically, object orientation is more likely to be a millstone than a miracle on your first project. Rather than your first project’s yielding great financial dividends, it may wind up costing you money for several reasons: The project team will take time to learn object orientation’s mysterious ways; you have the expense of acquiring and deploying new tools; and you have the set-up cost of library management. Also, your first object-oriented project will glean the least from reusability, because your initial library will probably comprise only foundation classes purchased from an outside vendor.

Fortunately, however, I believe that enough serious shops with realistic managers and adept technicians exist for object orientation to recover from the crash and backlash engendered by the less competent shops. In fact, it’s possible that object orientation will become a “shibboleth technology” that will separate the tribe of software engineers destined to thrive in the next millennium from the tribe destined to fade into oblivion.

3.3 Training

I’ve found that successful object orientation requires more, rather than less, training in general software-engineering principles than traditional systems development does. This is because the structures of object orientation are more complex than, say, those of a “structured design” system. For example, a modular system contains lines of code and modules (two levels of construction). An object-oriented system contains lines of code, methods and classes (three levels of construction). Furthermore, object-oriented classes are also organized into inheritance hierarchies. (To see the entire structure of even a small object-oriented system depicted on a single diagram is actually quite frightening!)

A special problem with object orientation is that the discipline has become undisciplined. A feeding frenzy has arisen among methods and training companies to ingest as much nutrition as possible from object orientation — the juiciest opportunity since “structured stuff”. Those who missed out in the 1970s and 1980s are determined not to miss out again!

This has resulted in a throng of folks with underwhelming software-engineering expertise who are now hanging out their object-oriented shingle. My pet peeve is the so-called experts who, from their usage, apparently don’t know the difference between a class and an object.

Fortunately, however, there are many serious and reputable companies out there who aren’t just cashing in. The problem is, of course, distinguishing the qualified trainers from the mavericks — another area where novitiate shops need to tread warily. (See also Appendix B for the seven stages of expertise that a person learning object orientation will go through.)

3.4 Shop maturity

Watts Humphrey has pointed out that organizations go through five levels, or ages, of software-engineering maturity. The terms we use at Wayland Systems Inc. for these ages are: Anarchy, Folklore, Methods, Metrics and Engineering. (See Appendix B for details of these five ages.)

Shops in the Age of Anarchy are a maelstrom of methods, with all the analysts and programmers doing their jobs in whatever manner they please. The Age of Folklore brings in some camp-fire lore about what works and what’s acceptable in the shop. There is, however, nothing formal about this age. The Age of Methods formalizes the shop’s approaches to building systems and increases likelihood of success by leaving less to chance.

The Age of Metrics introduces quantitative measurements of the system products and the processes that build the systems. Finally, in the Age of Engineering, producing systems becomes routine. Now the challenge is using metrics to improve the quality and productivity of the development process itself.

Unfortunately, lured by the “Fad of the Year,” many shops in the Age of Anarchy will attempt to introduce object orientation. The result will be that object orientation will get tossed into the shop’s swirling vortex of various techniques as just “another thing.” Management will give object orientation no support, most of its potential promise will go unrealized and — apart from a few die-hard zealots — object orientation will rapidly perish in ignominy.

A shop needs to be at least in the Age of Methods before it can maturely absorb, manage and exploit object orientation. A shop contemplating object orientation (or any other powerful systems approach) should therefore first assess its age of maturity and, if necessary, work on advancing this maturity. A shop that’s methodologically firmly rooted on dry ground is likely to make a great success of object orientation. However, for a shop that’s all at sea methodologically, object orientation may be the wave of the future that finally drowns them.

A shop that’s advanced to the Age of Metrics should capture quantitative evidence of the improvements — we hope! — that object orientation has brought. This firm evidence is especially useful when tides of methodological politics threaten to sweep in and gratuitously wash away the gains realized through object orientation.

3.5 Imperfections and confusion in the current object-oriented world

What do you need to build real systems? Lots of stuff, including: languages, compilers, linkers, debuggers, databases, design methods, design criteria, analysis methods, notation, CASE (Computer-Aided Software-Engineering) tools, metrics, ...

For traditional systems development, to a greater or lesser extent we’ve possessed all of the above facilities for 10, 20 or 30 years. With object-oriented systems we also possess to a greater or lesser extent all of the above — but in many cases we’ve had them for only 1, 2 or 3 years.

In other words, we’re currently at about “Version 1.2” of object orientation. Although just about everything we need for object orientation is here, nothing is as sophisticated as it will be five to ten years from now. Some of the facilities that we now have are awkward to use and there are many reports of development problems caused by the callowness of the object-oriented environment.

On the other hand, most of these problems are receding into the past, as object orientation, recently a revolutionary new approach to software, is now joining the mainstream of software techniques. A shop currently embarking upon object orientation is therefore no longer an early adopter and is no longer forced to navigate a dangerous, uncharted pioneering voyage to Terra Incognita.

4. The library

Be careful of what you want; you may get it! If the Angel of Reusability were to visit your shop tomorrow and offer you the fabulous Gift of Reusable Code, just about all of your managers would have the same reaction: “Where do I sign?”

But imagine for a moment that this actually happened. After the initial euphoria had worn off, everyone would start to realize that reusability comes at a price. Even if we assume for a moment that reusability is easy to achieve, what would you have to do actually to exploit it? The answer is: You’d have to develop and manage a class library, a storehouse of reusable object-classes.

4.1 Developing the library

There are many questions to ask before introducing a class library. The first is: How many libraries? The ideal answer, of course, is one. However, in a large corporation spanning many geographical locations, that’s hardly practical. You can’t store the library in only one physical location, on one physical disk. But how do you keep the libraries mutually consistent? You need physical configuration control.

Should there be levels of libraries, ranging from the small and local to the large and global, each one addressing a different scope (department, division, corporation) of reuse? And should the same degree of formality apply to all levels of library? What about multiple libraries, purchased from different vendors to fulfill different needs (such as graphics, finance, statistics and so on)? Again, how do you keep the libraries mutually consistent? You need logical configuration control.

My rule of thumb for developing a class library 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. When you’re building an in-house library, don’t skimp on this extra time. Don’t skimp on the development budget, the documentation budget or the maintenance budget. Deterioration will quickly set into the library if you do.

4.2 Caring for and feeding the library

Developing classes for a library, tough though it may be, is only half the battle. You must support and maintain your library. You must establish formal policies for entering, storing, retrieving and removing library holdings. In this subsection, I’ll mention just two library issues: one related to retrieving classes stored in the library and one related to entering classes into the library.

First, retrieving classes. If a programmer has to spend more than two minutes finding an appropriate reusable class in the library, the programmer will give up. He’ll then write the class over for himself. Ironically however, he may eventually enter this new class in the library alongside the similar class that he never found.

Second, entering classes. Most shops who undertake the creation of reusable code without having a plan for managing their libraries invariably wind up with a mess: classes missing vital methods; classes overlapping in functionality with other classes; classes that weren’t tested adequately; several incompatible versions of the same class; obscure classes with no documentation; and so on.

The best way to keep the class library under control is to appoint a librarian to oversee the activities of entering, storing, retrieving and removing code. The librarian’s first task is to defeat the problem of unsuitable code entering the library. The only classes that the librarian should allow in are classes that are consistent, non-redundant, tested and documented. (The librarian may be a small team, rather than a single person.)

Rather than being a passive rubber-stamper, a librarian should be hard-nosed. One of our clients refers to their current incumbent as “Conan the Librarian.” At that shop there’s a kind of dynamic tension between the librarian and the designers/programmers. The latter are rewarded for entering code into the library; Conan is rewarded for keeping it out!

It’s also important for your shop to have a library consultant (again, perhaps 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. The librarian(s) and library consultant(s) may comprise the same people.

It’s beyond the scope of this paper to delve further into library management. But I’m sure you can think of a score of other tasks that the librarians and library consultants must perform in order to keep a serious professional class library in good working order. (Two examples: publishing the library newsletter and the configuration management that I mentioned above.) Such tasks are not cheap but they must be seriously considered before leaping into object orientation.

5. Culture

Seldom to people realize, when they make a technological change that they will inevitably cause at least one cultural change too. In fact, a migration to object orientation there will cause several cultural changes. In this section, I cover three of the most important ones.

5.1 Culture and reusability

As we saw in Section 1, the reward of reusability can be substantial — perhaps a doubling of overall productivity. 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 that it takes in order to achieve reusability? Is everyone agreed that reusability is indeed the reason for the shop’s choice of object orientation?

One incident in particular brought home to me the importance both of knowing your reason for getting into object orientation and of sticking to that reason when life gets tough. This was the situation:

A corporation with a major software-development shop decided that software costs would be reduced considerably if they could build systems whose code consisted of at least 50% reused components. They also decided that object orientation was the technique of choice for achieving that reusability. So far, so good.

A group prepared an impressive management report outlining the advantages of object orientation. It was a good report, emphasizing results rather than techniques — clean hands rather than soap. Unfortunately, it dwelt too much on object orientation’s spectacular benefits (such as faster delivery of applications and reduced maintenance costs). It failed, however, to highlight the up-front investments needed for long-term reusability. Management expectations were thus raised to unsustainable levels.

With all this in place, the shop underwent the necessary training and tooling-up and set forth on their first object-oriented project, a project of about 20 people. It was a highly visible project in two ways: The application was strategically important and the project was the first to use the new, “high-productivity, rapid-delivery” object-oriented techniques.

But recall from Section 3 that object orientation has a severe “technology trap” associated with it. In other words, 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 money on purchasing and/or developing a robust library of reusable classes but will itself reap the fewest benefits from reusability. (This point is covered further in [Page-Jones, 1991].)

But let’s get back to the project. After 12 months, it was clear that the 18-month system-delivery deadline would not be met. Senior project members were called in and hauled over the coals. Their defense was that they’d invested the 12 months in designing a library of classes that would be robust enough to last through project after project. Upper management demanded that they abandon this time-wasting strategy and spend the remaining 6 months on the real work, coding the application itself.

I’ll spare you the gory details. 14 months later the project was abandoned in acrimony. The coding scramble that was to have lasted 6 months had been a disaster. It had immediately abandoned all pretense to planning, specification or design. People fell over one another in uncontrolled chaos.

There were two deliverables: a defect-ridden system that the users refused to accept and a library of classes that, although good, was woefully incomplete. This last point was irrelevant, however, since the shop was forbidden to use object-oriented techniques on future projects. The “Fad of the Year” had struck again!

The salutary moral of the tale is this: If you try to switch goals in mid-project, you may well fall between them and achieve neither goal. In this example, is the goal to lay down the long-term foundation for reusability, or is the chief goal to get the current system out as fast as possible? You should choose your goal for object orientation explicitly, make sufficient investment to realize it and then be earnest about achieving it.

5.2 Culture and organization

If a seasoned object-oriented shop has to write only 20% of the new lines of code per application that it used to, then the shop needs only about 20% of its former staff of programmers. Even though that’s simplistic arithmetic, there’s clearly a problem: What’s to be done with the surplus programmers?

One answer is to quintuple the amount of work that the shop carries out for the users. Wonderful! But a bottleneck will show up elsewhere — in analysis of requirements, for example. Therefore should we not rapidly retrain the extra programmers to become analysts? Not necessarily, because that may be a waste of training time and it may also annoy the programmer.

Although we don’t yet have all the answers to the questions of staff re-assignment under object orientation, it seems that there are several new positions that need to be filled. Therefore, the “extra programmers” should be re-trained and re-assigned into roles such as the following:

Triage-analyst (carrying out triage-analysis of existing systems: leave a system alone; introduce some object orientation into the system’s code by factoring out classes; or completely rewrite it)
Librarian (library manager)
Library consultant
Strategic library planner (planning the future direction, structure and contents of the library)
Library-class programmer — foundation level
Library-class programmer — business level
Application programmer/prototyper
Requirements analyst
Implementation designer
Toolsmith

This is not trivial stuff, organizationally, financially, culturally, emotionally or intellectually. I think that just a glance at the above list of roles will convince you that fully committed, long-term, successful adoption of object orientation is impossible without the support and understanding of all levels of management. So, if you really want code reusability, be sure that everybody is prepared to deal with the consequences. (Achieving analysis and design reusability raises similar issues that you’ll need to address.)

5.3 Culture and projects

Object orientation may call for a different sequence of activities from the traditional project lifecycle. Projects in an object-oriented shop begin with a mass of code already existing in class libraries. This significantly affects development sequence of a project as well as the cost/benefit analysis of the project undertaking. (For example, it’s certainly non-traditional to measure business requirements against a body of code readily able to meet some of those requirements cheaply.)

Also, as we saw, the care and feeding of the classes in the class library is very important. Each class will have its own lifecycle of immaturity, maturity and obsolescence. Therefore, for shops that adopt object orientation, the “waterfall” lifecycle doesn’t apply. Neither will a “whirlpool” (spiral) lifecycle apply completely. Perhaps object orientation requires a “Jacuzzi” model, reflecting the manifold small whirlpools created by the intersecting lifecycles of individual classes.

6. The bottom line on moving to object orientation

Finally, in summary, here are some don’ts and dos of making a successful transition to object orientation: Don’t:

Expect your first object-oriented project to go smoothly
Expect to reap much (or any!) financial reward from the first project
Tie the budget for introducing object orientation to a single project budget
Fall for the “Fad of the Year”
Expect the current world of object orientation to be mature and perfect
Feel you have to adopt every last aspect of object orientation all at once
Risk introducing object orientation if you’re in the Age of Anarchy
Build up unrealistic expectations
Skimp on training
Staff your projects entirely with Stage Threes
Become fixated on language training (especially C++)
Choose an analysis or design method just because it’s simple to understand
Skimp on library maintenance

Do:

Know the honest reason that you’re getting into object orientation
Make it a worthy reason that conforms to your long-term shop strategy
Find out whether your shop has the maturity to take on object orientation
Shore up your shop’s software-engineering foundations to support object orientation
Understand, publish and stay true to your project goals
Introduce object orientation on a pilot project
Plan to carry out sound analysis and design
Study a few analysis and design methods before choosing one
Perform a hands-on evaluation of a CASE tool before committing to it
Learn Eiffel or Smalltalk, whatever your shop’s chosen object-oriented language
Plan to have a robust, well-managed library, with a librarian and consultants
Foster and encourage reuse (including in analysis, design etc.)
Expect the shop’s culture to change
Consider novel career paths for your existing staff
Consider your object-oriented applications’ database needs
Get going sooner (not later) on introducing some object orientation into your shop
Monitor the changing world of object orientation through publications, conferences

Object Orientation: Making the Transition

Meilir Page-Jones

Abstract

1.1 Greater productivity

2.1 It’s the latest thing, isn’t it?

3.1 “The Fad of the Year”

5.1 Culture and reusability

5.3 Culture and projects

Appendix A: The five ages of sophistication

Age A — The Age of Anarchy

Age B — The Age of Folklore

Age C — The Age of Methodology

Age D — The Age of Metrics

Age E — The Age of Engineering

Appendix B: The seven stages of expertise

Stage One — Unaware

Stage Two — Aware

Stage Three — Apprentice

Stage Four — Practitioner

Stage Five — Journeyman

Stage Six — Expert

Stage Seven — Researcher

Bibliography