Features
- Cover Type: Paperback with 224 pages
- Published by: Microsoft Press August 9, 2006
- Written in: English
- ISBN 10 Number: 0735623198
- ISBN 13 Number: 978-0735623194
-
Book Dimensions:
8.8 x 7.3 x 0.7 inches
- Weighs: 1.2 pounds
Product Description
Here is the candid collected wisdom of Jim McCarthy, a
software industry veteran and the director of the
Microsoft Visual C++ development group. In McCarthy's words, "More people have ascended bodily into heaven than have shipped great
software on time"; but shipping great
software on time can be done, he insists, and this book tells how. DYNAMICS OF
software DEVELOPMENT is divided into five sections that chart the progress from initial design to successful product. Throughout, McCarthy expresses his sometimes-controversial judgments in witty, memorable maxims, one of which has become the title of the book. Destined to be a cult classic, DYNAMICS OF
software DEVELOPMENT will get a lot of attention in the industry and cause a favorable stir in the press.
Reader Reviews
This review is from: Dynamics of Software Development (Paperback)
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.
Search for books at
