Object Solutions : Managing the Object-Oriented Project (Addison-Wesley Object Technology Series)

Rating:
Summary: Please don't read this book
Review: A strong claim: this book is to be compared to Frederick Brook's The Mythical Man Month [1]. It is that important. Regardless of the fate of object-oriented technology, and the prospects are bright, this text will is already a classic in the making. One insight readers will enjoy is that object-oriented projects benefit from the same good management and technical skills as all other projects. The reverse is also true. It is an example of what Booch previously described as the total "round trip" gestalt (structure) [2]. Booch delivers an account of what these are with the insight and humor likely to make this text a classic. The first chapter, entitled First Principles, explores "When Bad Things Happen to Good Projects". He associates project failure with lack of risk management; building the wrong thing (solving the wrong problem); and being blind-sided by technology. One solution? Be proactive. The "five habits of successful object-oriented projects" can be applied to any project: a ruthless focus on satisfying a well-understood collection of essential minimal features; a culture focused on results, communication, and yet not afraid to fail; the use of (object--oriented) modeling; a strong architectural vision; the application of an iterative and incremental life cycle (p. 25). Booch distinguishes calendar driven, quality driven; documentation driven, requirements driven, architecture driven. Suffice to say focus on one does not mean throwing the others away. To be sure, no project survives for long without making its dates. Yet a chronic obsession with unrealistic, short term dates is a sign of a purely calendar driven project. Yet at crunch time what is the dominant decision making criteria? He considers the strengths and weaknesses of each. Calendar driven will work in the short run. But . . . "For all projects, overtime as a common practice is not only unsustainable, it is an indication of severe management malpractice" (p. 236). This is hard hitting, tell-it-like-it-is stuff. Requirements is the model of commercial applications. The dilemma? Requirements keep changing. Booch claims that architecture-driven projects have all the advantages of requirements-driven with the additional benefit of "encouraging the reaction of resilient frameworks that can withstand shifting requirements and technological calamity" (pp. 20 -21). The second chapter on Products and Processes sets up the mainline of development. The Macro Process (Chapter 3) is closely related to the traditional waterfall life cycle. It is the domain of the software management team. It provides the framework for the Micro Process (Chapter 4), which is closely related to the spiral (iterative) model of development, in which prototyping plays such a central role. Throughout the discussion, Booch emphasizes the benefits or producing "tangible artifacts" (prototypes(user interface), architecture documents, style guides, working software). These "help reduce risk by forcing strategic and tactical decisions out in the open" (p. 60). The Macro Process begins with a section on "The One Minute Methodology". The Micro Process starts out with a section on "I'm OK, My Program's OK". That's what the micro process is about -- programming. Here the focus is on building "cool stuff" with the available technology. The sixth chapter on management and planning beings with a section on "Everything I Need to Know I'll Learn in My Next Project" (p. 229). The point is that good project management is simply "a call for adult supervision" (p. 230). This includes steps to "aggressively seek out risks and question all assumptions" (p. 230). These must be judged against the project's "essential minimal characteristics" (p. 230). The number of times the expression "managing risk" occurs in this text is significant. Duly noted. The final chapter of Special Topics is a nice overview of special problems with different kinds of systems: user centric (extra effort on the end-user interface), data centric (extra effort on the database model), distributed (extra effort on the network), computation centric (extra effort on the algorithms), legacy systems (extra effort on the system interface), real time systems (extra effort on performance). Throughout this discussion Booch provides a wealth of concise, amusing, and insightful sayings. For example, "...The very act of building a system raises questions of behavior that no reasonable amount of analysis can uncover efficiently (p. 87)". "JAD is a high-ceremony approach whose basic principles can be reduced to the one sound bite: "Hey . . let's talk to real users about what they want!" (p. 101). In summary, this text provides the reader with the Zen of project management. An obvious audience for this book is the project manager. She or he will be rescued from having to "suck wind" because a robust, flexible architecture is able to accommodate the last minute changes in requirements. Apparent contradictions are mediated. The actual contradictions are addressed by simulating, providing for the method "as if" system development were a rational process. Building software is an engineering process; and, as such, entails real world compromises implementable and usable by human beings. All roles in software development, from top management to code pusher, will benefit from Booch's experience and insights into the process. References [1] Brooks, F. The mythical man-month. Addison-Wesley, Reading, MA, 1975. [2] Booch, G. Object-oriented analysis and design with applications. Benjamin/Cummings, Redwood City, CA, 1994. --this review was originally submitted to Computing Reviews, but since they had someone else review the book, they did not want it -- so here

Rating:
Summary: Booch takes no prisoners -- insightful, humerous, brilliant
Review: A strong claim: this book is to be compared to Frederick Brook's The Mythical Man Month [1]. It is that important. Regardless of the fate of object-oriented technology, and the prospects are bright, this text will is already a classic in the making. One insight readers will enjoy is that object-oriented projects benefit from the same good management and technical skills as all other projects. The reverse is also true. It is an example of what Booch previously described as the total "round trip" gestalt (structure) [2]. Booch delivers an account of what these are with the insight and humor likely to make this text a classic. The first chapter, entitled First Principles, explores "When Bad Things Happen to Good Projects". He associates project failure with lack of risk management; building the wrong thing (solving the wrong problem); and being blind-sided by technology. One solution? Be proactive. The "five habits of successful object-oriented projects" can be applied to any project: a ruthless focus on satisfying a well-understood collection of essential minimal features; a culture focused on results, communication, and yet not afraid to fail; the use of (object--oriented) modeling; a strong architectural vision; the application of an iterative and incremental life cycle (p. 25). Booch distinguishes calendar driven, quality driven; documentation driven, requirements driven, architecture driven. Suffice to say focus on one does not mean throwing the others away. To be sure, no project survives for long without making its dates. Yet a chronic obsession with unrealistic, short term dates is a sign of a purely calendar driven project. Yet at crunch time what is the dominant decision making criteria? He considers the strengths and weaknesses of each. Calendar driven will work in the short run. But . . . "For all projects, overtime as a common practice is not only unsustainable, it is an indication of severe management malpractice" (p. 236). This is hard hitting, tell-it-like-it-is stuff. Requirements is the model of commercial applications. The dilemma? Requirements keep changing. Booch claims that architecture-driven projects have all the advantages of requirements-driven with the additional benefit of "encouraging the reaction of resilient frameworks that can withstand shifting requirements and technological calamity" (pp. 20 -21). The second chapter on Products and Processes sets up the mainline of development. The Macro Process (Chapter 3) is closely related to the traditional waterfall life cycle. It is the domain of the software management team. It provides the framework for the Micro Process (Chapter 4), which is closely related to the spiral (iterative) model of development, in which prototyping plays such a central role. Throughout the discussion, Booch emphasizes the benefits or producing "tangible artifacts" (prototypes(user interface), architecture documents, style guides, working software). These "help reduce risk by forcing strategic and tactical decisions out in the open" (p. 60). The Macro Process begins with a section on "The One Minute Methodology". The Micro Process starts out with a section on "I'm OK, My Program's OK". That's what the micro process is about -- programming. Here the focus is on building "cool stuff" with the available technology. The sixth chapter on management and planning beings with a section on "Everything I Need to Know I'll Learn in My Next Project" (p. 229). The point is that good project management is simply "a call for adult supervision" (p. 230). This includes steps to "aggressively seek out risks and question all assumptions" (p. 230). These must be judged against the project's "essential minimal characteristics" (p. 230). The number of times the expression "managing risk" occurs in this text is significant. Duly noted. The final chapter of Special Topics is a nice overview of special problems with different kinds of systems: user centric (extra effort on the end-user interface), data centric (extra effort on the database model), distributed (extra effort on the network), computation centric (extra effort on the algorithms), legacy systems (extra effort on the system interface), real time systems (extra effort on performance). Throughout this discussion Booch provides a wealth of concise, amusing, and insightful sayings. For example, "...The very act of building a system raises questions of behavior that no reasonable amount of analysis can uncover efficiently (p. 87)". "JAD is a high-ceremony approach whose basic principles can be reduced to the one sound bite: "Hey . . let's talk to real users about what they want!" (p. 101). In summary, this text provides the reader with the Zen of project management. An obvious audience for this book is the project manager. She or he will be rescued from having to "suck wind" because a robust, flexible architecture is able to accommodate the last minute changes in requirements. Apparent contradictions are mediated. The actual contradictions are addressed by simulating, providing for the method "as if" system development were a rational process. Building software is an engineering process; and, as such, entails real world compromises implementable and usable by human beings. All roles in software development, from top management to code pusher, will benefit from Booch's experience and insights into the process. References [1] Brooks, F. The mythical man-month. Addison-Wesley, Reading, MA, 1975. [2] Booch, G. Object-oriented analysis and design with applications. Benjamin/Cummings, Redwood City, CA, 1994. --this review was originally submitted to Computing Reviews, but since they had someone else review the book, they did not want it -- so here

Rating:
Summary: A MUST read BEFORE a projectmanager's 1e OO project.
Review: Booch talks about managing the object oriented project in his well known 'easy to read' style. The complete object oriented project life cycle is discussed in depth. This is great reading stuff for people only accustomed to the 'classic' Waterfall model. I personally was enlighted to read about the 'Prototype' or 'Proof of concept' phase. What makes the book exceptionally usefull are the 'Key Practices' and 'Rules of thumb'. These are integrated in the text, but also listed seperately in de appendices. These insights and experiences give the book a very pratical value. Certainly when not having any OO project experience yourself, these Key Practices and Rules of thumb give you a head start. This book is a MUST read for any projectmanager involved in managing object oriented software projects. Preferably before his or hers first object oriented project.

Rating:
Summary: A MUST read BEFORE a projectmanager's 1e OO project.
Review: Booch talks about managing the object oriented project in his well known 'easy to read' style.The complete object oriented project life cycle is discussed in depth. This is great reading stuff for people only accustomed to the 'classic' Waterfall model. I personally was enlighted to read about the 'Prototype' or 'Proof of concept' phase. What makes the book exceptionally usefull are the 'Key Practices' and 'Rules of thumb'. These are integrated in the text, but also listed seperately in de appendices. These insights and experiences give the book a very pratical value. Certainly when not having any OO project experience yourself, these Key Practices and Rules of thumb give you a head start. This book is a MUST read for any projectmanager involved in managing object oriented software projects. Preferably before his or hers first object oriented project.

Rating:
Summary: Please don't read this book
Review: Half-way through this book I decided I wanted to burn every copy of the book. If other people read this book, then they'll all know how to manage object-oriented software projects too!

Rating:
Summary: A must have
Review: I had no hesitation to give 5 stars here. The book is really very good. Honestly, what do you expect with such a book ? To learn valable advices, to understand them, and to have fun while reading. Such a book exists : this one ! How many time I asked to myself "Yes ! What a good idea ... and so simple" or "Of course ! That's it". I really read it like a novel. You can bring it with you for your hollidays (like me), without the feeling to get boring with professional stuff !

Rating:
Summary: Fly On The Wall
Review: I swear that Booch was spying on several of the so called "projects" that I was a developer on. It is simply amazing to me how many times the so-called "Harvard School of Business" techniques are used to manage an OO project! I have learned through the school of hard knocks what Booch has written about in this book (wish I had discovered it sooner, a couple of pointy haired bosses could have used it!). Anyway, Booch breaks OO management into seven chapters: First Principles, Products and Process, The Macro Process, The Micro Process, The Development Team, Management and Planning, and Special Topics. I especially found interesting his descriptions on how NOT to run an OO project (oh, and he gives plenty of examples on HOW to run one too!). Booch covers OOA, artifacts, OOD, methodolgies (a biggy with me even on a one person project), evolution (gosh! who would have thought you could have cyclical development???). Identification of classes, objects, symantecs, relationships, etc. He then tackles the team environment: roles and responsibilities (especially the manager's responsibilities!), resource allocation, and tools (this book is not a plug for Rational Rose BTW). Finally: managing risk, planning and scheduling, staffing, costing (a tough one), Quality Assurance (this is not testing!), and he talks some about projects in crisis and what to do. The last chapter is kind of a catch-all containing: User-centric, Data-centric, and Computation-centric systems discussions, along with Distributed, Legacy, Information Management, and Real Time Systems. The appendicies contain: a summary of recommended practices (for those wanting to create a methodology), and rules of thumb. There is a great index, bibliography and glossary to tie up the package nicely. Booch has a terrific writing style presenting what would normally be a dry subject! Definitely for the computer Project Manager's shelf!

Rating:
Summary: Fly On The Wall
Review: I swear that Booch was spying on several of the so called "projects" that I was a developer on. It is simply amazing to me how many times the so-called "Harvard School of Business" techniques are used to manage an OO project! I have learned through the school of hard knocks what Booch has written about in this book (wish I had discovered it sooner, a couple of pointy haired bosses could have used it!). Anyway, Booch breaks OO management into seven chapters: First Principles, Products and Process, The Macro Process, The Micro Process, The Development Team, Management and Planning, and Special Topics. I especially found interesting his descriptions on how NOT to run an OO project (oh, and he gives plenty of examples on HOW to run one too!). Booch covers OOA, artifacts, OOD, methodolgies (a biggy with me even on a one person project), evolution (gosh! who would have thought you could have cyclical development???). Identification of classes, objects, symantecs, relationships, etc. He then tackles the team environment: roles and responsibilities (especially the manager's responsibilities!), resource allocation, and tools (this book is not a plug for Rational Rose BTW). Finally: managing risk, planning and scheduling, staffing, costing (a tough one), Quality Assurance (this is not testing!), and he talks some about projects in crisis and what to do. The last chapter is kind of a catch-all containing: User-centric, Data-centric, and Computation-centric systems discussions, along with Distributed, Legacy, Information Management, and Real Time Systems. The appendicies contain: a summary of recommended practices (for those wanting to create a methodology), and rules of thumb. There is a great index, bibliography and glossary to tie up the package nicely. Booch has a terrific writing style presenting what would normally be a dry subject! Definitely for the computer Project Manager's shelf!

Rating:
Summary: Good but a difficult read.
Review: The content and arrangement of the material is excellent, but Booch is stuck in long unusual vocabulary "Abstractionist" that makes this book a hard sell for the management audience. I would like to see a translated version for mortals! Technically precise jargon is pardonable in detail books, like OOAD, but turns-away the managers who could most benefit from it. By contrast, Steve McConnell's "Rapid Development" is a vastly more approachable read

Rating:
Summary: Bad paper
Review: The information inside is great but publisher use very bad paper (Like paper used in yellow newspapers) to save $1.