Dynamics of Software Development

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.

The title of the book, " 'Dynamics' of Sofware Development", describes very well how this book differs from the rest of Software Development Management books.If you are looking for Gantt charts and templates for software specs, there are other good books out there for you.This book is about the "Dynamics" of creating great software.If you want to learn how to channel the chaos of a software team (department, company) into a powerful and unified force, to lead your team (whether or not you are the official "project manager") to create great products, to win every time, and to just plain enjoy work, this is the book.Some scientist once said "A great theory, formulated well, is just common sense". When you read the book, you will have many "aha!" moments as you realize the real dynamics behind your current project challenges. The appropriate actions will be just "commonsense" after that.The book gives you the context of the real dynamics of software, a good framework (the five stages), practical know-how of how to create high-performance software teams, and a tremendous set of tools to communicate what's going to those around you (I particularly like "don't shake the jello").I bought the book soon after I founded my company, when there were only 10 people sitting in a cramped office. Since then, we've grown tremendously (public on NASDAQ), and use many of the concepts in the book in our organizational design for the R & D group.This book is one of the 7 non-technical books I consider as the cornerstone of any software development library.Highly recommended.

Someone truly understands this crazy world of software development. I could not be more impressed with a book - and guess what, it is language _and_ system independent. Not only this, it is for developers, engineers, QA engineers, technical writers and managers alike.This book provides such keen insight into the problems and complexities of full life cycle development and support, project management and system architectural initiatives that you would think McCarthy was sitting in on every design and architecture meeting you have ever attended -scary!I have never been so impressed with a single technical book in my career, and it does not even require a computer - only a desire to get along with each other, raise our intellect a few notches, and develop solutions on time. Not only this, it is 5 years old, which in techy years, makes it timeless.I applaud!

You hear a lot today that talent is so scarce, esp. in the field of programming. Well, that's one of the biggest lies of our times. I've found Jim McCarthy's book extremely helpful in finding valuable characteristics programmers have. Programming is a lot more than just writing code and this book will help you see that. It'll encourage you to find out the other parts of software development and how people who may not know the latest buzzwords are nevertheless far more capable than the industry tends to give them credit.It'll definitely cause you to question your processes of software development (do you have any where you work?), esp. if you believe that your way is the only way. Programming is much more about problem solving, so will you be versatile enough to welcome the many ways that many gifted individuals are able to design and create software, even when it's not what you originally had in mind?I've found the Appendix extremely helpful. I love the part where Jim explains that the biggest mistake hiring managers make is their present obsession with buzzwords of the day, buzzwords which 2 to 4 years later become obsolete. Instead, what's really needed is to understand how a programmer uses technology to solve the problems at hand. The way programmers are evaluated during job interviews are in many places so inaccurate as this book points out, and you'll also get some ideas as to how to rectify this.Probably the only people I have found who are not turned on by this book are those who say that software development and computers in general have no place for "touchy-feely" aspects like motivation and job satisfaction. But for those who want to find more of a human connection with the programming they do, I highly recommend it. That especially goes for managers in high-tech who usually get promoted because of their technical abilities alone. These same managers get no training in management, esp. in the handling of people skills. This book is indeed a great investment to begin learning some of these vital skills, esp. when so many say they got into high-tech professions like Information Technology because such occupations don't have to deal with hot human issues like egos and office politics. Guess again!Lastly, my other favorite part within the book is the comparison of a well-run software organization with that of an awesome jazz band. Jazz lets individuals solo and improvise while the accompanying team provides an invigorating backdrop. And individuals each get a chance to solo, supported by team members' respect and admiration. I've experienced tremendous highs playing in both great jazz ensembles and software teams. Now you can too!

I'm not going crazy, the software development environment is really like this. Jim gave me the "rules" and terminology to communicate the challenges of this profession to my managers. This book created a common bond among the software developers on my team to help us through our projects. A must read for every software project manager and the whole team. (Also give a copy to your manager).