Home > Store

Surviving Object-Oriented Projects

Register your product to gain access to bonus material or receive a coupon.

Surviving Object-Oriented Projects


  • Sorry, this book is no longer in print.
Not for Sale


  • Copyright 1998
  • Dimensions: 7-1/4" x 9-1/4"
  • Pages: 280
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-49834-0
  • ISBN-13: 978-0-201-49834-9

Today, many organizations claim competitive market advantages resulting from the application of object-oriented technology and approaches in their software development efforts. As the use of object technology has become increasingly widespread and mainstream, a growing number of project managers are faced with a daunting task: keeping the object technology project on track and within budget. These project managers are burdened by the weight of knowing that the survival and ultimate success of the project hinges on their insight when planning the project and their responses to events that lie ahead. Unfortunately, hidden costs, unpleasant surprises and unrealistic expectations lie in wait for the unprepared manager.

Although much has been written about object technology and the benefits of this paradigm, there is still a shortage of compiled knowledge about what to expect and to plan for during project implementation. This book provides information that managers need to combat the unforeseen challenges that await them, allowing them to survive and ultimately succeed with an object-oriented project.

To provide practical advice and guidelines for successfully managing an object-oriented project, the author borrows from the seasoned wisdom of numerous experts and successful consultants while also drawing on his personal experience and extensive knowledge. Surviving Object-Oriented Projects: A Manageris Guide points out potential hazards and names workable solutions by addressing the important issues of scheduling, budgeting, staffing, and cost justification. Key points are supported and illustrated through short case studies taken from real object-oriented projects, and an appendix collects these workable guidelines and solutions into brief icrib sheetsio ideal for handy reference.


Sample Content

Online Sample Chapter

Selecting and Setting Up an OO Project

Table of Contents



1. Success and Failure.

Basic Concepts.

Object Technology.







Incremental and Iterative Development.

2. Project Expectations.

Project Histories.

Alfred: Success with Changing Requirements.

@AHEADS = Brooklyn Union Gas: Success Through Attentiveness.

Ingrid: Success in Migrating to C++.

Manfred: Failure in Prototyping.

Mentor Graphics: Trouble Migrating to C++.

Object Technology International: Success in Productivity and Speed.

Reginald: Failure with Changing Rules.

Stanley: Too Much Cutting Edge.

Tracy: Failure Through Naivete.

Udall: Success by Restarting Smaller.

Winifred: Inattentive but Persistent.

Possible Benefits of Object Technology.

Responsiveness to Variations on a Theme.

Responsiveness to Change.


Communication Between Developers, Users, and Executives.




Window-Based User Interfaces.


Automated Code Generation.

Software Process.

OO Design, Encapsulation, and System Evolution (Tom Morgan).


Are You Underestimating.

Time to Get New Developers Productive.

Immaturity of the OO Industry.

Hazards of C++.

The Difficulty of Reuse.

Establishing a Software Process.

Business Modeling versus Software Design.

The Cost of CASE Modeling Tools.

Probable Costs.

Nonobject Issues Checklists.

3. Selecting and Setting Up an OO Project.

Project Suitability.

Variations on a Theme.

Simplified Program Structure.

Memory Management Features.

What Is Not Suited.

Project Purpose.





Other Project Categories.


Executive Sponsor.

Project Manager.

Technical Lead.

Technical Staff.


Personality Types.


The Selection Process.

One Person is Persuasive or Stubborn.

The Team Knows a Similar Technology.

The Technology is Safe, Popular, or Standard.

The Technology is the Rational Choice.

Programming Languages.

Managing Smalltalk.

Managing C++.

Disciplined Use of C++ (Jeremy Raw).

Managing OO COBOL.

Managing Java.


Upper-CASE Tools.

Using Java (Sam Griffith).

The Scanner Challenge.

Minimum CASE Tool Requirements.

The Cutting Edge.

Training and Getting Advice.

What to Teach.

Developers Do Not Know How to Think in Objects.

Developers Do Not Know How to Make Design Trade-Offs.

Developers Program Poorly or Use Tools Badly.

Different Programmers Write Differently, Making The Code Hard to Learn.

Developers Create Redundant Classes Because They Do Not Know What Is in the Class Library.

No One Knows How to Document a Framework Well.

Developers Do Not Understand Their Role On The Project And Who Depends on Them.

When to Teach.

Getting Advice.

Legacy Issues.


Relational Databases.

Project Setup (C.D.).


4. Getting Started.


Big-M Methodology.

A Base Methodology to Tailor.

Discussion of the Methodology.

Roles, Skills, Techniques.







Building Consumer Understanding of the Design (Ward Cunningham).


Two Weeks per Noncommercial Class.

Domain Classes.

Screen Classes.

Utility Classes.



An Estimation and Planning Session (Alistair Cockburn).



Take the Time to Design.

Design, and Two Smalltalk Projects (K.L.).

5. Making Corrections.

A Study Project.

Stage 0: The Usual Ignorance.

Stage 1: Disaster.

Stage 2: Rebuild.

Stage 3: Improve.

Stage 4: Functioning.

Stage 5: Overconfidence in Scaling Up.

Lessons From This Study Project.

Managing Precision, Accuracy, and Scale.

Managing Work According to Precision and Accuracy.

Increments and Iterations.

Increments and V-W Staging.


Combining Increments and Iterations.

Burn Some Pancakes (Luke Hohmann).

Project Increments.

Increment 1.

The Architecture Team.

The Training Team.

The Intentions.

Two Stories.

Increment 2.

Pause and Learn.

Move On.

Increment N.

User Involvement.

Watching Users (K.L.).

Project Teams.


Involve the Users (Jon Marshall).

Total-Ownership Teams.

Matrixed Teams.

Domain Modeling and Reuse.

The Domain Model.

Hazardous Situations.

The Common Domain Model.

Why Are There Multiple Valid Domain Models.


Conflicting Reward Systems.

Lack of Trust.

I Can Write It Faster Myself.

Further Reading.

6. Advice From Hindsight.

Costs and Benefits Revisited.

Sentences You Hope Never to Hear.

Writing 500 Lines of Code per Day.

Model the World, Then Code.

Design the Screen, Then Code.

Iterate Prototypes.


Reuse is Easy.

More on Iterations.


Two Increments Delivered.

Thirty People.

Analysts, Programmers, and Tools.

Learning OO From the Compiler.

Programmers Between Projects.

On the Cutting Edge.

Designers and Programmers Separated.

Six-Month Pilot Started.

7. Expand to Larger Projects.

Your First Big Project.

Project Charter.


Staffing, Skill Dilution, and Project Teams.


Increments and Iterations.

The Cutting Edge.

Domain Modeling.

Risk Reduction.


Class Duplication.

Training the Tidal Wave.

Ten Lessons the Hard Way (Glenn House).

Train Fewer People.

Train More Effectively.

Training 50 or More People.

Set up a Full-Time Classroom Program.

Set up 6 to 10 Connected Projects.

Use a Full-Time Mentor.

Maintain Tight Standards and Review Policies.

Rotate People.



Staff Skill Mix.

Team Structure.

Even Mix.

Progress Team/Training Team.

Productivity Changes Over Time.

Lines of Code Per Month.


Productivity Revisited.

Migrating the organization.

8. Rechecking a Case Study.

Winifred Revisited.



Stage 1: Good Start, with Experience and Support.

Stage 2: No Architecture, Almost No First Delivery.

Stage 3: New Increment; Add Teams, Mentors, Architecture.

Stage 4: Owner per Deliverable; New Infrastructure.


Relation to Book's Topics.

Technology Is Only Part of the Story.

Organizations (Jim Coplien).

Appendix A. Collected Risk-Reduction Strategies.

Appendix B. Crib Sheet.

Index 000 0201498340T04062001


If you are thinking of starting, or have already started, an object-oriented (OO) project, and want to know what you are up against, this book will be of use to you. Organizations that have successfully made the transition to object technology claim significant time-to-market reduction. Developers say object orientation is a fun way to develop software.

There is no shortage of literature on the subject; however, the press has made so much of object technology that it is hard to sort out exaggerations and selective reporting from the actual experience one can expect. Speakers rarely seem to want to name the actual costs of making the move to objects, perhaps to avoid scaring away future newcomers.

There is, therefore, a lack of information on what sorts of unpleasant surprises await one when starting an OO project, and what to do about them. It is this lack of information that Surviving Object-Oriented Projects: A Manager's Guide addresses.


This book covers issues I have found in several dozen organizations that are doing object-oriented projects. From failed efforts, we learned specific difficulties; from successful projects, we learned how to get around the difficulties.

The early reviewers of this book unanimously said that it takes several projects to apply the lessons. They said that people on their first OO project are not sufficiently aware of the issues to detect them, are not yet open to suggestions, and cannot set aside old habits and thinking patterns. It is my hope that you can prove them wrong, that you will succeed on your first, or your second, project by paying attention to the lessons from other people's experiences.

This book is not a primer on object technology, nor is it a primer on object-oriented design techniques or of macro- or micromanagement. It is not a technical review of the literature, nor a cataloging of project types. Despite all that has been written about object orientation, there is still a shortage of compiled knowledge of what happens on a project. The information in this book is based on personal project experiences--my own, those of people I have interviewed, and interviews I have read. The project leader will come up against numerous, specific topics for which an answer cannot easily found in the literature, or the obvious answer does not work.

In this book, I identify topics, point out hazards and name a workable strategy taken from a project that successfully cleared the hazard. The hazards and strategies are collected at the back of the book in Appendix B, Crib Sheets.

For readers interested in companion texts to this book, I recommend David Taylor's Object Technology: A Manager's Guide (Reading, MA: Addison Wesley, 1990), Grady Booch's Object-Oriented Analysis and Design (Reading, MA: Addison Wesley, 1994) and his Object Solutions (Reading, MA: Addison Wesley, 1996).


Surviving Object-Oriented Projects: A Manager's Guide is intended for the busy professional. Here is a reading strategy four types of possible readers:

  1. The executive scanning for impact to the organization. Read the Preface and the first two chapters. These take you through concepts, project histories, expectations, and costs. If you are interested in the next level of depth, skim the setup issues involving project selection and staffing, and the chapters on large projects. At that point, you may wish to give the book to the project manager.
  2. The manager before starting on a project. Read Chapters 1, 2, 3, and 5 of the book. These cover expectations, project setup, and incremental and iterative development. Then look through the list of strategies (Appendix A) and hazards (Appendix B) at the back of the book to get a sense of the total set of issues.
  3. The manager on a project. The primary audience for this book is the manager on a project, working with the technical lead. Some issues are technical enough to require terms of object technology. You, the project manager, may find that the technical lead will bring these problems to your attention or will help you work through them. Skim the entire book to get the nature and location of topics. When working on the project, look up particular topics as they occur. The chapters are organized in roughly the order topics usually show up and need to be dealt with. Reread Chapter 5 about making corrections before each increment.
  4. The project's technical leader. Use the book to help your manager understand certain issues, such as organizing teams, developing iteratively, and resisting unproductive tools and activities. I have added technical depth in a few areas where a project hazard lurks and there is no simpler way to carry through on the discussion.

Among these are: simplistic modeling of the business (sometimes passing under the name of "analysis"), overstaffing at the beginning of a project, and false productivity measures. For some issues, it is up to you, the technical leader, to work with the arguments in the book to convince other developers and the management team to adopt a sensible direction.

I have included an extended section on C++ because it is my carefully considered opinion that C++ represents an additional hazard to the survival of the project. If you favor using C++, read through this section and deal with the issues to ensure your project's success.


The book has eight chapters and two appendices, roughly matching the chronology of encounter with the issues.

  • Chapter 1 summarizes and introduces sucess and failure factors, and defines terms you will have to become familiar with.
  • Chapter 2 is a reality check. What expectations do you have about object technology, and how should you adjust those expectations? The chapter contains stories about a dozen projects, which are referred to throughout the book
  • Chapter 3 deals with selecting and setting up a project. This is the best place to work on survival, even if survival means walking away from the project. It covers all the standard issues of staffing, training, tool selection, methodology, legacy systems, and the like.
  • Chapter 4 covers some basic issues you will encounter when running the project: estimates, plans, milestones, measurements--and design.
  • Chapter 5 deals with the inevitable corrections you will have to make. I start by citing my favorite project, which started dismally and then was turned around. From this project, we can learn a great deal about tuning. You will have much tuning to do; do not feel bad about making changes during the project.
  • Chapter 6 is written as a reflection on the first five chapters. You can pretend that you have just finished your project and are giving advice to another person who is about to start a project. What would you highlight for him or her? Here is where you can get hindsight in advance.
  • Chapter 7 addresses organizations that have safely made it to the point (or declared themselves at the point) of committing large numbers of their staff to using object technology. There are new costs and new dangers lying in wait for those who move on to larger projects.
  • Chapter 8 is another reality check in which I compare the contents of the book to a real project. It opens the topic of organizational culture in overall software success.
  • Appendix A is a collection of 12 success strategies presented in a medical diagnosis metaphor.
  • Appendix B is a summary, a "crib sheet," to copy and tape to the wall as your daily reminder about the basics of an object-oriented project.

Throughout the book, the topics cross-reference each other extensively. To keep the reading uncluttered, the links to other pages are noted in the margin with a page number, as shown here. Your project's survival depends on developing your insights and reflexes. To help you develop them, I use material taken primarily from first- and second-hand experiences, my own and those of the many people I have interviewed. I devote space to a few published papers, which were carefully done and provide insights. They are noted in footnotes or in further reading sections in some of the chapters.


I thank the nontechnical people around me: Kieran, Sean, Cameron, Deanna. I now know why so many authors thank their families. Thanks also to the people at Beans & Brew, who provided good coffee, a good atmosphere, and good conversation. As Plato said:

Only if the various principles--names, definitions, intimations and perceptions--are laboriously tested and rubbed one against the other in a reconciliatory tone, without ill will during the discussion, only then will insight and reason radiate forth in each case, and achieve what is for man the highest possible force. . . .

This book received much benefit from the testing of principles and the "rubbing together" of ideas in conciliatory tone and without ill will. For that I thank the following individuals:

  • Bruce Anderson, IBM Object Technology Practice
  • Carol Burt, President, 2AB, Inc.
  • Dave Collins, Outback Software, Ltd.
  • Anton Eliens, Vrije Universiteit (Amsterdam)
  • Adele Goldberg
  • David Gotterbarn, East Tennessee State University
  • Brian Henderson-Sellers, Swinburne University of Technology
  • Jeremy Raw, Independent Consultant (Durham, NC)
  • Arthur J. Riel, Vangaurd Training, Inc.
  • Cecilia Shuster
  • Dave Thomas
  • Daniel Tkach, IBM Consulting Group
  • Rebecca Wirfs-Brock
  • The editors at Addison-Wesley

for helping to improve the book. I am indebted to Sam Adams for the terms big-M and little-m methodology, and to Dick Antalek and Wayne Stevens who taught me the most about big-M methodologies. I also want to thank the authors of the Eyewitness Accounts for taking time to contribute their knowledge about object-oriented projects:

  • Jim Coplien, Bell Labs, (formely AT&T)
  • Ward Cunningham (Cunningham & Cunningham)
  • C.D., Independent Consultant
  • Harvie S. Griffith, Jr. (Sam), President, Object Methods Software
  • Luke Hohmann, SmartPatents
  • Glenn House, Formerly of Mentor Graphics
  • K.L., Independent Consultant
  • Jon Marshall, ParcPlace-Digitalk
  • Tom Morgan, Brooklyn Union Gas
  • Jeremy Raw, Independent Consultant

K.L. and C.D. asked that I not use their names, in order not to discomfit any companies. All these people were kind enough to contribute their experience to this book. They may not agree with everything I write, but we all share the wish to help you succeed on your project.



Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020