Customer Reviews

Dynamics of Software Development

5 star:		(26)
4 star:		(3)
3 star:		(2)
2 star:		(3)
1 star:		(2)

 

 

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!

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.

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.

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!

McCarthy's book is an absolute must-read for anybody managing or involved with software development. His "Rules" and case histories make this book an invaluable text on what to do and what not to do. Not an academic treatment of project management, this little gem is the first book I've seen on this topic that deals with the psychology, sociology, *and* management issues of creating intellectual property in a timely manner within a team environment.

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).

I first read Dynamics of Software Development a few years ago. I've re-read it twice since. Each time I find tips that address the very issues we face in Software Development. Most of our issues in delivering on time and within budget have to do with our ability to understand and communicate our expectations with each other. We have a tendency to write off people we don't agree with. Jim challenges us to resolve the communication issues and get to results by never "flipping the Bozo Bit" on ourselves or others. Jim also stresses the importance of Vision and accountability - keys to success. Thanks!!

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.

McCarthy lays out a series of simple high-level thoughts about software development. Once you read each point, I would recommend that you take some time to flesh out each point and apply it to your particular development situation. Some ideas come with practical applications and some don't. Overall, a fairly good book that will get you thinking or re-thinking development.

This is the best book I've read on software development social issues (and I've read a number of them). If you are managing software projects and don't have it, get it now.