Rating: 
Summary: Many good ideas that others continue to reuse.
Review: Despite the occasional lapse into speech resembling the Microsoft line and the relative age of the book, the message this book contains is still applicable. Software development is a very hard, (perhaps the hardest of all), thing to do and humans have yet to master it. McCarthy was a primary manager of the original Microsoft Visual C++ project and when he joined the group, it was in shambles. There was a lack of direction, and contrary too much of the published data, most C programmers had not yet made the transition to coding in C++. While it was true that the developers were using compilers that understood C++ source code, the code they were developing was a slightly modified C code that was translated using a C++ compiler. Under his direction, the Visual C++ team created a package that automated many of the complex, yet largely routine tasks of using C++, doing much to spread the use of the language.
McCarthy has since become an evangelist for sensible software practices, and he has preached his sermons in many locations. The essence of those sermons is condensed into the 54 software development "rules" that appear in this book. Most of them continue to appear in the continuous cycle of books professing to put forward new, (so to speak), ways of developing software. For example, number 18, "Cycle Rapidly", is one of the fundamental principles of Extreme Programming, about which a large number of books have been written. Number 56, "Every milestone deserves a no-blame postmortem.", is the fundamental principle of the book, "Project Retrospectives: A Handbook for Team Reviews" by Norman L. Kerth and published by Dorset House in 2001.
Therefore, since having your ideas repeated by experts who come later is the highest form of confirmation that they are good, there is no doubt that the ideas in this book are well worth reading. I have not investigated the chronology of the main ideas of software development that are currently bandied about, but it is quite possible that some of them first appeared in this book.
Rating: 
Summary: An Epiphany for Software Developers & Managers
Review: For several years I've been aware that the biggest obstacles to overcome in producing high quality software are not technical but psychological. Finally here is a software engineering book that deals effectively with these problems.Jim McCarthy explains the psychology behind cooperative vs competitive behaviours and gives you practical techniques that you as a software development leader can undertake. People make decisions based upon emotions more often than on intellect; that's a reality. If you've ever wanted to act as an agent of change, you will know that you fail more often than you succeed and its risky. Giving someone advice that they haven't asked for is tricky. When management creates an atmosphere where people feel safe about sharing their ideas & creating a shared vision and an evolutionary technology plan, then your group will become as supercharged as a V12 Pratt & Whitney engine! This book would revolutionize software development if more people read it and understood it. It's great for technical recruiters too. Jim explains how to recognize the super achievers instead of trying to recruit an alphabet soup of acronyms. Most people who write a review for this book are those who really liked it. The reviewers who didn't like it, hate it. I suspect technical people are going to find this book hard to swallow or are going to have a real preconceived antipathy, because they are focused upon their own achievements without regard to how they should behave as a team. This is due to a failure on the part of management to set forth these principles & guidelines. Certainly you can't expect to institute meaningful change if you are only a developer with limited influence, however this book gives you a framework to communicate to management.
Rating:
Summary: Stories that stick in your head long after reading
Review: I found this book to be quite helpful, amusing, as well as sobering as I thought of past projects and situations I've been involved/leading. Each of the dynamics is laid out one per chapter --- Jim M. illustrates each one with a solid story including personalities and teams which show the emotions that people feel while participating in complex development work. Lots of useful principles to employ in motivating people and teams (not just for software development). By the way, this book has principles and stories...this is not a step by step or "how to" on software project management. You'll need to get materials from Steve McConnell or Fergus O'Connell for that.
Rating: 
Summary: Not Quite...
Review: the read of McConnell's 'Software Project Survival Guide' or 'Rapid Development'. Its a hard read with vague areas as well as over the sky areas. I hate the stupid pictures, waste of at least 50 pages. Trying to find a subject is hard , all content is hiden in vagueries. Read McConnell first.
Rating:
Summary: Common Sense That Is Not So Common
Review: This book delivers great insight into what goes on in software development. Although presented in the context of work performed on Microsoft Visual C++ 1.0, the author does a good job of generalizing specific experience. McCarthy gives us an honest look into the ups and downs without sugar coating or promising silver bullets. Presented in a format similar to Meyers' "Effective C++" books, the text flows very well and is a pleasure to read. When you read many of the pitfals presented, you may think "Duh!". However, these are things that I see happen regularly. Here are some of the highlights. Rule #2 "Get Their Heads Into The Game". This sounds like a very simple rule. Everyone on the team needs to be contributing ideas toward creating intellectual property. However, most people know this is easier said than done. McCarthy goes on to explain the barriers to the flow of ideas. Rule #4 "Don't Flip The Bozo Bit". This rule is necessary to keep #2 working. The author deals with the natural tendency that people have to become defensive when criticism is offered of their ideas. This can actually cause both the critic and the one being criticized to tune each other out. The author suggests that team members call each other on it when the Bozo Bit is being flipped. Rule #25 "Don't Accept Dictation". This topic is addressed in many other texts, but that fact should tell us that we aren't getting it. McCarthy reminds us that it is foolish to accept dictation of scheudle, features, and resources. The "Holy Triangle" has to be balanced and tradeoffs are required when changing any one of these three. Managers are encouraged to be strong and take a stand when they find themselves in this situation. Eight years after this book was published, I still see this very thing happening. Until something changes, we will continue to see this issue addressed in software management texts. Rule #31 "Beware Of A Guy In A Room". Software development is a collaborative effort. Don't let people isolate themselves. There is no opportunity for feedback or help when problems arise, and this can derail the project. The appendix on "Hiring And Keeping Good People" is also very helpful. If you are like most managers, you didn't get to hire most of the people that work for you. Here you will find practical advice for letting your superstars reach their potential and getting something out of everyone.
Rating:
Summary: Common Sense That Is Not So Common
Review: This book delivers great insight into what goes on in software development. Although presented in the context of work performed on Microsoft Visual C++ 1.0, the author does a good job of generalizing specific experience. McCarthy gives us an honest look into the ups and downs without sugar coating or promising silver bullets. Presented in a format similar to Meyers' "Effective C++" books, the text flows very well and is a pleasure to read. When you read many of the pitfals presented, you may think "Duh!". However, these are things that I see happen regularly. Here are some of the highlights. Rule #2 "Get Their Heads Into The Game". This sounds like a very simple rule. Everyone on the team needs to be contributing ideas toward creating intellectual property. However, most people know this is easier said than done. McCarthy goes on to explain the barriers to the flow of ideas. Rule #4 "Don't Flip The Bozo Bit". This rule is necessary to keep #2 working. The author deals with the natural tendency that people have to become defensive when criticism is offered of their ideas. This can actually cause both the critic and the one being criticized to tune each other out. The author suggests that team members call each other on it when the Bozo Bit is being flipped. Rule #25 "Don't Accept Dictation". This topic is addressed in many other texts, but that fact should tell us that we aren't getting it. McCarthy reminds us that it is foolish to accept dictation of scheudle, features, and resources. The "Holy Triangle" has to be balanced and tradeoffs are required when changing any one of these three. Managers are encouraged to be strong and take a stand when they find themselves in this situation. Eight years after this book was published, I still see this very thing happening. Until something changes, we will continue to see this issue addressed in software management texts. Rule #31 "Beware Of A Guy In A Room". Software development is a collaborative effort. Don't let people isolate themselves. There is no opportunity for feedback or help when problems arise, and this can derail the project. The appendix on "Hiring And Keeping Good People" is also very helpful. If you are like most managers, you didn't get to hire most of the people that work for you. Here you will find practical advice for letting your superstars reach their potential and getting something out of everyone.
Rating:
Summary: Excellent overview for development managers
Review: This book is a clear and concise set of practical advise to create a positive software development environment and deliver software on time. Microsoft has not traditionally been known to deliver software on time but the principals in this book allowed the early Visual C++ team to deliver on time and solidify marketshare.
Rating:
Summary: Place on Your Team's Reference Shelf
Review: This book is a great book for development managers (those who manage software development projects)! Read it cover to cover and highlight the important summary paragraphs throughout the book for easy reference later. If you're a senior manager, then read it and get all of your development managers a copy for reference.
Rating:
Summary: The "agile" story of Visual C++
Review: This books describes Jim McCarthy's story on developing Visual C++ 1.0. The method of development has much in line with the agile development methods at this moment. Quotes like "embrace the change" are now quite common but were less common in 1995. The book is written in a very funny way. It's not always easy to follow the author but that doesn't really make it much worse. Jim McCarty puts very much effort on the "group psyche" and focus on team work and communication. He tries to describe on how to make a team with a "winning mood" which then should take all responsibility and 'just' finish the product. Parts like "Group psyche", "Don't flip the bozo bit", "The world changes and so should you" and "slip but don't fall" are extremly good and useful to read! When reading the book I really got the feeling that he knows how to ship great intellectual property. And the success of the Visual C++ compiler also shows that his methods have been very successfull. The second edition of the book will be released in 2 days from now (6 Feb. 2004) and that's certainly a book which I will read again! Great stuff.
Rating:
Summary: The "agile" story of Visual C++
Review: This books describes Jim McCarthy's story on developing Visual C++ 1.0. The method of development has much in line with the agile development methods at this moment. Quotes like "embrace the change" are now quite common but were less common in 1995. The book is written in a very funny way. It's not always easy to follow the author but that doesn't really make it much worse. Jim McCarty puts very much effort on the "group psyche" and focus on team work and communication. He tries to describe on how to make a team with a "winning mood" which then should take all responsibility and 'just' finish the product. Parts like "Group psyche", "Don't flip the bozo bit", "The world changes and so should you" and "slip but don't fall" are extremly good and useful to read! When reading the book I really got the feeling that he knows how to ship great intellectual property. And the success of the Visual C++ compiler also shows that his methods have been very successfull. The second edition of the book will be released in 2 days from now (6 Feb. 2004) and that's certainly a book which I will read again! Great stuff.
| 
