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.
1. Success and Failure.
Incremental and Iterative Development.
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.
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.
Nonobject Issues Checklists.
Variations on a Theme.
Simplified Program Structure.
Memory Management Features.
What Is Not Suited.
Other Project Categories.
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.
Disciplined Use of C++ (Jeremy Raw).
Managing OO COBOL.
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.
Project Setup (C.D.).
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.
An Estimation and Planning Session (Alistair Cockburn).
Take the Time to Design.
Design, and Two Smalltalk Projects (K.L.).
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).
The Architecture Team.
The Training Team.
Pause and Learn.
Watching Users (K.L.).
Involve the Users (Jon Marshall).
Domain Modeling and Reuse.
The Domain Model.
The Common Domain Model.
Why Are There Multiple Valid Domain Models.
Conflicting Reward Systems.
Lack of Trust.
I Can Write It Faster Myself.
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.
Reuse is Easy.
More on Iterations.
Two Increments Delivered.
Analysts, Programmers, and Tools.
Learning OO From the Compiler.
Programmers Between Projects.
On the Cutting Edge.
Designers and Programmers Separated.
Six-Month Pilot Started.
Your First Big Project.
Staffing, Skill Dilution, and Project Teams.
Increments and Iterations.
The Cutting Edge.
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.
Staff Skill Mix.
Progress Team/Training Team.
Productivity Changes Over Time.
Lines of Code Per Month.
Migrating the organization.
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).
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:
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.
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:
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:
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.