Back in print, one of the first practical, hands-on books about working with and managing software development teams now comes with a video presentation of “21 Rules.” Its insights are classic and still relevant today.

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 34 Ratings

Many good ideas that others continue to reuse. - 2003-10-30
Reviewer Rating:
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.

10 out of 10 - changed the way I developed software - great to have it back - 2006-10-02
Reviewer Rating:
This book (when first published) formed a major part of the turn towards Agile for me and my development teams in the 1990's.
When I first read Dynamics I realised that software development could become fun and creative again. Building software didn't need to be a trudge through schedules, missed deadlines, working with 'bozos' and finger pointing.
I have used the ideas from Dynamics for over 10 years now in the software development teams I have run, worked with, trained and mentored. In the 1990's I bought multiple copies of this book for the teams I worked with. In those work places it was recommended (in some places compulsory) reading and I believe still should be for many software development teams.
It is fantastic to see this book back in publication and hopefully a new generation of developers will learn to create great products and reach their potential.

Things I love about Dynamics:
1. easy to dip into the book and read a rule (or three) and get value from them without having to read the book from the begining to the end.
2. written from the trenches, at the time of writing it Jim and Michele worked at Microsoft on the Visual C++ team. There are many good stories in the book from the trials and tribulations of that team.
3. common sense writing that often makes you think "Doh! why are we not doing that?"
4. you don't have to buy into everything in the book, take what works for you now and come back later to grab more value when you are ready for it
5. the 4 stages of the development lifecycle partition the rules cleanly
6. all the original content from the first edition is still there

Software For Your Head by Jim and Michele, although full of great ideas, proved hard to read and requires commitment to get to the end. I am very pleased to see the Core protocols and commitments from Software for your Head updated and added to the end of Dynamics. This time the Core is presented in a much easier to digest format.

Interesting book - 2008-01-15
Reviewer Rating:
I have not found this book as interesting as the type of books that I usually read. I prefer books dealing with the more technical aspects of software development. I have read this book because I need to acquire a solid base of knowledge on software project management and not because the topics covered in the book seemed fun and interesting to me. Even if I was not very enthusiast to read it, I must confess that the author made a great job making his book interesting to read by interleaving important concepts with anecdotes from his work experience.

This book is divided into 54 short advices each taking 1 to few pages to expand the rational behind the advice. This is a format that I like and the advices that I have preferred were the ones dealing with the psychological aspect of software development. An example of such rule is that software quality is the mirror of the state of mind of the team. For some this might be obvious but considering the book intended readers which consist of engineers and software professionals, the author has been wise to be explicit on this topic in my opinion as from experience, human interactions is usually not the strongest skill among developers.

The part that seems to me to be outdated is the whole proposed economical model to market software. The author advocates that to make money from software, you must release often like every year and by doing so, your customers will be so happy that they will gladly hand you more money year after year. I think this model used to be true when the software industry was still young 20 years ago but in 2008, the software products are so mature that no matter how hard you try to squeeze more new features, it will not be enough to justify for people to purchase the new version when that last one does everything you want. You just have to think about the sales of Windows Vista or Microsoft Office 2007 to see what I mean. Changing just for the sake of changing does not sell.

In my opinion this model should be changed to one where incremental small evolutions are proposed to customers. I would be willing to pay a small amount of money every year for an OS that is smaller, better and faster at each version. I do not get it how software companies can expect people to be interested in slower and more bloated products than the previous version. Add the possibility to purchase inexpensive add-ons to fill very specific needs to the model and you have a very attractive model. I am not sure if what I would like to see is representative to what the typical customer expects or if my proposal is viable in real life but one thing is sure. The model proposed in the book does not seem to work anymore for many mature businesses.

There is a 2006 edition of this book. I might take a look in it to find out if the advices that I have found outdated have been reworked.

Dynamics of Software Development - 2007-10-30
Reviewer Rating:
This book is the best book I have ever read on the issues of getting a team to successfully develop software. Jim McCarty is wise and has great insight into what it takes to get a large group of people to work together to create intellectual property.

I highly recommend this book.

The "agile" story of Visual C++ - 2004-02-04
Reviewer Rating:
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.