Surviving Object-Oriented Projects

Description

• 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.

0201498340B06012001



Sample Content

Online Sample Chapter

Selecting and Setting Up an OO Project

Table of Contents

Preface.


Acknowledgements.


1. Success and Failure.

Basic Concepts.

Object Technology.

Class.

Object.

Inheritance.

Encapsulation.

Polymorphism.

Framework.

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.

Time-to-Market.

Communication Between Developers, Users, and Executives.

Maintainability.

Reuse.

Productivity.

Window-Based User Interfaces.

Morale.

Automated Code Generation.

Software Process.

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

Costs.

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.

SWAT.

Investigative.

Production.

Full-Commit.

Other Project Categories.

People.

Executive Sponsor.

Project Manager.

Technical Lead.

Technical Staff.

Users.

Personality Types.

Technology.

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.

Tools.

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.

Mainframes.

Relational Databases.

Project Setup (C.D.).

Review.

4. Getting Started.

Methodology.

Big-M Methodology.

A Base Methodology to Tailor.

Discussion of the Methodology.

Roles, Skills, Techniques.

Tools.

Teams.

Ownership.

Deliverables.

Standards.

Activities.

Building Consumer Understanding of the Design (Ward Cunningham).

Estimates.

Two Weeks per Noncommercial Class.

Domain Classes.

Screen Classes.

Utility Classes.

Frameworks.

Plans.

An Estimation and Planning Session (Alistair Cockburn).

Milestones.

Measurements.

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.

Iterations.

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.

Ownership.

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.

PolyBloodyHardReuse.

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.

Classes.

Reuse is Easy.

More on Iterations.

Self-Test.

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.

Communication.

Staffing, Skill Dilution, and Project Teams.

Methodology.

Increments and Iterations.

The Cutting Edge.

Domain Modeling.

Risk Reduction.

PolyBloodyHarderReuse.

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.

Productivity.

Size.

Staff Skill Mix.

Team Structure.

Even Mix.

Progress Team/Training Team.

Productivity Changes Over Time.

Lines of Code Per Month.

Frameworks.

Productivity Revisited.

Migrating the organization.

8. Rechecking a Case Study.

Winifred Revisited.

Summary.

History.

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.

Analysis.

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

Preface

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.

Scope

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).

Audience

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.

Organization

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.

Acknowledgments

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.

0201498340P04062001



Updates

Submit Errata

