Surviving Object-Oriented Projects: A Managers Guide (Addison-Wesley Object Technology Series) by Alistair Cockburn, Alistair Cockburn (Editor), Rebecca Wirfs-Brock (Foreword by)

From the Publisher

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 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 Manager's 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 guidelines and solutions into brief "crib sheets" - ideal for handy reference.

Booknews

Synthesizing the insights of managers and consultants who have lived to tell the tale, offers advice on keeping a software development project using object-oriented technology and approaches on track and within budget despite the inevitable pitfalls that await. Includes a tear-out crib sheet with handy data and some soothing mantras to chant. Annotation c. by Book News, Inc., Portland, Or.

Product Details

• ISBN: 0201498340
  
• ISBN-13: 9780201498349
• Format: Textbook Paperback, 250pp
• Publisher: Addison-Wesley
• Pub. Date: December 1997
• Series: Agile Software Development Series

• Table of Contents
• Forewords & Introductions
• Read an Excerpt

Table of Contents

Forewords & Introductions

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

Read an Excerpt

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'sexperiences.

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.