What do you think?
Rate this book
Dynamics of Software Development
In 1995, Jim McCarthy captured the attention of the software development industry with DYNAMICS OF SOFTWARE DEVELOPMENT—offering thought-provoking ideas, techniques, and strategies for delivering great software on time in the real world. Now, this classic book is back—complete with new insights and additional material. You get the 54 original Rules—including new commentary for the 2006 Edition—with realistic guidance for organizing, managing, and working on any software development team. Adding to these insights, the McCarthys meditate on three new Rules exploring the balance of critical relationships among team members. You’ll also briefly examine The Core. A system of protocols stemming from The Rules, The Core helps teams reach a shared vision and work together more effectively to deliver great software. To complete the McCarthys� tapestry, this 2006 Edition includes a CD with the original video presentation that sparked this book’s first edition and helped influence an entire generation’s approach to software development. CD A Note Regarding the CD or DVD The print version of this book ships with a CD or DVD. For those customers purchasing one of the digital formats in which this book is available, we are pleased to offer the CD/DVD content as a free download via O'Reilly Media's Digital Distribution services. To download this content, please visit O'Reilly's web site, search for the title of this book to find its catalog page, and click on the link below the cover image (Examples, Companion Content, or Practice Files). Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to [email protected].
224 pages, Paperback
First published August 1, 1995
10 people are currently reading
492 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 15 of 15 reviews
January 25, 2021
I read this � along with Code Complete and Rapid Development in the mid-90s when I was first learning how to make software in a professional environment. It opened my eyes, for the first time, to the idea that we were doing it wrong; that there was a better way.
Re-reading it 25 years later I am shocked at how far we have come. So far, in fact, that McCarthy's DSP no longer seems relevant to my life or to the craft of software development in the 21st century. So many of McCarthy's wonderful observations and tips and heuristics apply to a world that no longer � or should no longer � exist.
I arrived in Silicon Valley in 1996 to work at a brand new startup and here's a typical release for us from that period:
Step 1. Marketing Requirements Document.
The product managers go off into a room for 3 or 4 months to produce a marketing requirements document (MRD). For reasons that I don't remember, it was very important that they not talk to any software developers during that period.
Step 2. Scope negotiation.
With the volume turned to 11, product management would argue with the engineering managers and senior developers about how much we could achieve in the next release. They would agree on a release that dissatisfied everyone.
Step 3. Functional specs.
Developers would spend a few weeks writing functional specs to describe how they would realize the MRD. Nobody read them.
Step 4. Technical specs.
Developers would spend a few weeks writing technical specs to describe how they would realize the functional specs. Nobody read them.
Step 5. Code like hell!
This would be the shortest step but it was a doozy.
Step 6. Code Complete.
I was important to have "the happy path" done at least 6 weeks before the release so that testers would have time to test and documentation folks would have time to document.
Narrator: The code was not complete.
During this period, testers would report bugs since it was the first time that anyone other than the author had looked at the code. Developers would say "No user would ever do that" a lot or "that's not the happy path and I'm still working on that bit".
Step 6. Code Freeze.
It was important to stop coding several before the release because testers could not test the code while developers were still changing it.
Narrator: We did not stop coding.
During this period, developers would already be working on their specs for the next release and if someone asked them a question they would respond with "Do you mean on the previous release"?
Final Step. Ship Party!
Laser tag! Movies at Page Mill! Virtual Reality Jet Fighters!
Software development was in a bad way in the 90s but McCarthy and McConnell and Brooks et al helped us survive our mad pursuits for a few more years until Kent Beck told us in XP Explained how we should have been making software all along.
Don't bother reading this book unless it's still 1997 where you are. Read the Art of Agile Development by Jim Shore instead.
/book/show/1...
/book/show/9...
/book/show/4...
/book/show/6...
Re-reading it 25 years later I am shocked at how far we have come. So far, in fact, that McCarthy's DSP no longer seems relevant to my life or to the craft of software development in the 21st century. So many of McCarthy's wonderful observations and tips and heuristics apply to a world that no longer � or should no longer � exist.
I arrived in Silicon Valley in 1996 to work at a brand new startup and here's a typical release for us from that period:
Step 1. Marketing Requirements Document.
The product managers go off into a room for 3 or 4 months to produce a marketing requirements document (MRD). For reasons that I don't remember, it was very important that they not talk to any software developers during that period.
Step 2. Scope negotiation.
With the volume turned to 11, product management would argue with the engineering managers and senior developers about how much we could achieve in the next release. They would agree on a release that dissatisfied everyone.
Step 3. Functional specs.
Developers would spend a few weeks writing functional specs to describe how they would realize the MRD. Nobody read them.
Step 4. Technical specs.
Developers would spend a few weeks writing technical specs to describe how they would realize the functional specs. Nobody read them.
Step 5. Code like hell!
This would be the shortest step but it was a doozy.
Step 6. Code Complete.
I was important to have "the happy path" done at least 6 weeks before the release so that testers would have time to test and documentation folks would have time to document.
Narrator: The code was not complete.
During this period, testers would report bugs since it was the first time that anyone other than the author had looked at the code. Developers would say "No user would ever do that" a lot or "that's not the happy path and I'm still working on that bit".
Step 6. Code Freeze.
It was important to stop coding several before the release because testers could not test the code while developers were still changing it.
Narrator: We did not stop coding.
During this period, developers would already be working on their specs for the next release and if someone asked them a question they would respond with "Do you mean on the previous release"?
Final Step. Ship Party!
Laser tag! Movies at Page Mill! Virtual Reality Jet Fighters!
Software development was in a bad way in the 90s but McCarthy and McConnell and Brooks et al helped us survive our mad pursuits for a few more years until Kent Beck told us in XP Explained how we should have been making software all along.
Don't bother reading this book unless it's still 1997 where you are. Read the Art of Agile Development by Jim Shore instead.
/book/show/1...
/book/show/9...
/book/show/4...
/book/show/6...
January 27, 2020
An entertaining ramble through the concerns that should plague anyone who works on a software development team, and particularly their managers, through the course of a project.
The book is structured as a series of 'rules', broken into sections that represent the phase of the project. The rule titles are often quite abstract (e.g. "Don't shake the Jell-O") and while they make sense with the accompanying text, they might not stand well by themselves. This gets to major issue with the book, the authors style is very descriptive and entertaining, but as often as this helps illustrate his point, it clouds and confuses his message. It can lead to some excellent quotes (I've added some of the best to this review) but it often feels like his editor should have made him take out half of the adjectives and pick which phrase best lays things out instead of all three.
As this book is now 25(!) years old, some of his advice is simply best practice these days, but there aren't many modern books that do as good a job of covering the arc of a project and various issues that afflict development teams. Some of these psycho-social insights are still valuable, but occasionally he veers into evolutionary anthropology or other questionable rationalizations and it all gets a bit Hacker News. For example, there's a particularly grating section where he discusses a woman who clearly wanted to move into management and instead of supporting that they get her to define an entirely new job that, frankly, sounds like management.
Ultimately, this is as worthy a read as for the useful advice and the historical context it provides, even if time has exposed some of its weaknesses.
And now those quotes:
The book is structured as a series of 'rules', broken into sections that represent the phase of the project. The rule titles are often quite abstract (e.g. "Don't shake the Jell-O") and while they make sense with the accompanying text, they might not stand well by themselves. This gets to major issue with the book, the authors style is very descriptive and entertaining, but as often as this helps illustrate his point, it clouds and confuses his message. It can lead to some excellent quotes (I've added some of the best to this review) but it often feels like his editor should have made him take out half of the adjectives and pick which phrase best lays things out instead of all three.
As this book is now 25(!) years old, some of his advice is simply best practice these days, but there aren't many modern books that do as good a job of covering the arc of a project and various issues that afflict development teams. Some of these psycho-social insights are still valuable, but occasionally he veers into evolutionary anthropology or other questionable rationalizations and it all gets a bit Hacker News. For example, there's a particularly grating section where he discusses a woman who clearly wanted to move into management and instead of supporting that they get her to define an entirely new job that, frankly, sounds like management.
Ultimately, this is as worthy a read as for the useful advice and the historical context it provides, even if time has exposed some of its weaknesses.
And now those quotes:
The unrelenting natural tendency in software development is to transmute hopes and wishes into peculiar reality distortion fields.
Software expresses the team that created it.
Self expression is irrepressible in the act of creating software.
Put time into your design ... Time is one ofhte primary media with which you are working ... A product which is not designed to ship on time, won't.
Everyone on the team is engaged in the process of software development: everyone is a developer
The end of software development is software developers
If yo uask a developer the status of something they are working on, they might be correct, but if so it's a coincidence
Slipping is like waking up from that software dream, getting closer to reality
Development develops developers
November 25, 2021
I read this book a few years after it was published in 1995 and was unpleasantly surprised by important aspects of the Microsoft culture it indirectly portrayed, although some of the insights on software development project management were quite valuable especially if you were working on (for the time) large multi-team efforts.
The first thing that struck me rereading the book in 2021 is how closely the management style espoused by McCarthy anticipates so many features of agile development. Of course, back in the day, Boehm was already exploring spiral developments and other authors were exploring "lightweight" processes design.
If you lived through software development in the 1990s, this book will probably strike a sympathetic chord with you. If you started programming in the 21st century, I would not recommend plowing through this book in search of still valid nuggets, since you will probably wince at what now appears to be its somewhat rambling and disjointed style, its naive, somewhat high-handed psychological and sociological theories and its lack of concrete examples and the number of what at the time seemed like fresh insights that have now become commonplaces of agile development.
The first thing that struck me rereading the book in 2021 is how closely the management style espoused by McCarthy anticipates so many features of agile development. Of course, back in the day, Boehm was already exploring spiral developments and other authors were exploring "lightweight" processes design.
If you lived through software development in the 1990s, this book will probably strike a sympathetic chord with you. If you started programming in the 21st century, I would not recommend plowing through this book in search of still valid nuggets, since you will probably wince at what now appears to be its somewhat rambling and disjointed style, its naive, somewhat high-handed psychological and sociological theories and its lack of concrete examples and the number of what at the time seemed like fresh insights that have now become commonplaces of agile development.
August 4, 2020
This book is not well written, but contains a wealth of insight into the psychology of creating software. The author helped manage the creation of Visual C++. He talks a lot about morale and people work. This book is really intended for a manager type, but I enjoyed the overview.
June 13, 2016
Mixed feelings on this one. The author clearly knows a lot about delivering software and articulates his insights very well. On the other hand, I would say that mostly in the 2nd half of the book everything becomes very abstract and psychology-based. Being a bit skeptical (I can admit ignorant possibly) about psychology, and I realise it might be the semantics of possibly the most misused term ever, I basically get lost and struggle to understand how to go from the abstract level the author describes to something applicable to software development projects. All of this results on that I don't know very well what to make of all this psychological part.
This is a summary of the things that really resonated with me, either because I agree based on my experience or they align with my thoughts:
- The importance of QA to keep projects real.
- Establishing a shared vision for a project is fundamental.
- Tell your truth to everyone who doesn't understand a problem. Ignore personal hang-ups and kick off a discussion.
- Every idea and associated belief from the team is worth evaluating, if only again to elicit a discussion and improve our understanding.
- Don't put up with sloppy work even if management asks for it. Just move on.
- "The only consensus worth having is a creative one achieved in the combat of fully engaged intellects"
- No approach is right or wrong but an ongoing compromise between features, resources and time.
- "Given that it's extremely difficult (probably impossible) for a team of committed professionals to create a schedule that even approximates the rate at which the product ultimately materializes, it's utter madness that in many organizations the dates, the features, and the resources of a software development project are dictated by people unfamiliar with developing software"
- One of the non-negotiables, possibly the most important, is that only the person / team doing the work should be estimating the effort it will take.
- We as humans strive for predictability and software projects fall prey to delusions of pseudo-order as a maladaptive defense against uncertainty.
- Our goal running software projects shouldn't be to foresee the future and produce a correct plan but manage the development and react as new information is been uncovered.
- Tasks should be structured in a way that we come up with small deliverables in a continuous flow in a small, short period cadence.
- Meeting a milestone if we can't track progress is a random effort. It hugely pays off to invest in clarity of specificity about what we are delivering in every little goal.
- Moving the goalposts (scope, time, quality) is acceptable and beneficial if and only if you retrospect and learn about the problem. This introspection will lead to meet later, more critical milestones.
- It is not about achieving the initial goals but to achieve the maximum potential and benefits given constraints on time and resources.
- "Slipping is not the problem. Being surprised by slipping is the problem. (...) the organization is broken. People aren't thinking. People aren't talking to each other. People aren't aware of the global situation."
This is a summary of the things that really resonated with me, either because I agree based on my experience or they align with my thoughts:
- The importance of QA to keep projects real.
- Establishing a shared vision for a project is fundamental.
- Tell your truth to everyone who doesn't understand a problem. Ignore personal hang-ups and kick off a discussion.
- Every idea and associated belief from the team is worth evaluating, if only again to elicit a discussion and improve our understanding.
- Don't put up with sloppy work even if management asks for it. Just move on.
- "The only consensus worth having is a creative one achieved in the combat of fully engaged intellects"
- No approach is right or wrong but an ongoing compromise between features, resources and time.
- "Given that it's extremely difficult (probably impossible) for a team of committed professionals to create a schedule that even approximates the rate at which the product ultimately materializes, it's utter madness that in many organizations the dates, the features, and the resources of a software development project are dictated by people unfamiliar with developing software"
- One of the non-negotiables, possibly the most important, is that only the person / team doing the work should be estimating the effort it will take.
- We as humans strive for predictability and software projects fall prey to delusions of pseudo-order as a maladaptive defense against uncertainty.
- Our goal running software projects shouldn't be to foresee the future and produce a correct plan but manage the development and react as new information is been uncovered.
- Tasks should be structured in a way that we come up with small deliverables in a continuous flow in a small, short period cadence.
- Meeting a milestone if we can't track progress is a random effort. It hugely pays off to invest in clarity of specificity about what we are delivering in every little goal.
- Moving the goalposts (scope, time, quality) is acceptable and beneficial if and only if you retrospect and learn about the problem. This introspection will lead to meet later, more critical milestones.
- It is not about achieving the initial goals but to achieve the maximum potential and benefits given constraints on time and resources.
- "Slipping is not the problem. Being surprised by slipping is the problem. (...) the organization is broken. People aren't thinking. People aren't talking to each other. People aren't aware of the global situation."
April 12, 2014
Dynamics of Software Development is a classic guide for software development management, written during a time (mid 90's) where large software development teams were mostly creating desktop software with large up-front costs - think WordPerfect, Lotus 1-2-3, Microsoft Excel, and Microsoft Word.
Jim McCarthy is a product of one of the most successful of these large software houses - Microsoft - and while some of his insights are clearly outdated (such as his his description of the customer relationship in the middle of the book, and the once-universal 18-month software update cycle, etc.), most of the book is full of still-relevant wisdom that any good software development team would be wise to follow.
The book is comprised of two basic types of content (divided into various sections you can discover on your own by reading the book):
1) Rules of Thumb
These are catchy phrases such as, "Get their heads into the game", "Don't flip the bozo bit", "Be an authority, not an authority figure", etc. There is value in everyone of these rules, but some (as stated already) are somewhat thin with age.
2) The Core Protocols
Since publishing the first edition of this book, McCarthy and his wife/business partner launched a consulting company with the goal of helping teams get into a state of shared vision. Through their numerous trainings they discovered a set of activities that, if followed, will bring your team into that shared vision state - guaranteed. The protocols themselves are interesting, but I'm not sure implementation would be possible without team-wide training and follow up.
Perhaps better than any other author, McCarthy illustrates the value of intellect in the creation of intellectual property. The more minds you get focused on that task, the more IP you'll develop. Most of the book focuses on getting individuals and teams on the same page, moving in the same direction, giving themselves the best chance of creating not just shippable but great software. In fact, McCarthy's thoughts on greatness are some of the most insightful in the book.
Given it's diminutive size, low cost (you can get it online for less than $10 + shipping), and easy-flowing prose, I recommend this book for anyone serious about creating great software.
Jim McCarthy is a product of one of the most successful of these large software houses - Microsoft - and while some of his insights are clearly outdated (such as his his description of the customer relationship in the middle of the book, and the once-universal 18-month software update cycle, etc.), most of the book is full of still-relevant wisdom that any good software development team would be wise to follow.
The book is comprised of two basic types of content (divided into various sections you can discover on your own by reading the book):
1) Rules of Thumb
These are catchy phrases such as, "Get their heads into the game", "Don't flip the bozo bit", "Be an authority, not an authority figure", etc. There is value in everyone of these rules, but some (as stated already) are somewhat thin with age.
2) The Core Protocols
Since publishing the first edition of this book, McCarthy and his wife/business partner launched a consulting company with the goal of helping teams get into a state of shared vision. Through their numerous trainings they discovered a set of activities that, if followed, will bring your team into that shared vision state - guaranteed. The protocols themselves are interesting, but I'm not sure implementation would be possible without team-wide training and follow up.
Perhaps better than any other author, McCarthy illustrates the value of intellect in the creation of intellectual property. The more minds you get focused on that task, the more IP you'll develop. Most of the book focuses on getting individuals and teams on the same page, moving in the same direction, giving themselves the best chance of creating not just shippable but great software. In fact, McCarthy's thoughts on greatness are some of the most insightful in the book.
Given it's diminutive size, low cost (you can get it online for less than $10 + shipping), and easy-flowing prose, I recommend this book for anyone serious about creating great software.
April 11, 2015
This book changed my life. It is based on a talk that Jim McCarthy gave while at Microsoft teaching people how the Visual C++ team went from the goats of the company (which was founded on languages, not operating systems of office applications), to the premiere group, shipping on time and using a newly invented subscription model. The art in the book is worth the price alone. The advice is timeless and none of the "rules of thumb" will ever go out of style no matter which agile practice is the rage today.
My favorite rule is "Beware a man in a room", related to to the "Don't go dark" rule. These are rules which say beware when your best programmer has locked herself in a room and is always "almost" done. Jim says it's almost always a guy - which is probably true, but I've seen it with both genders and it is never pretty. Don't go dark just means, always offer status to your group regardless of being asked - it's like a radio station - keep working, but don't go dark.
There are plenty of books about agile this, and lean that, but this is the one that started it all.
Jim was agile before agile was cool. My autographed copy is a prize on my shelf.
My favorite rule is "Beware a man in a room", related to to the "Don't go dark" rule. These are rules which say beware when your best programmer has locked herself in a room and is always "almost" done. Jim says it's almost always a guy - which is probably true, but I've seen it with both genders and it is never pretty. Don't go dark just means, always offer status to your group regardless of being asked - it's like a radio station - keep working, but don't go dark.
There are plenty of books about agile this, and lean that, but this is the one that started it all.
Jim was agile before agile was cool. My autographed copy is a prize on my shelf.
November 23, 2021
More than 10 years ago Jim McCarthy wrote the first edition of Dynamics of Software Development. At that time it was a great book. It helped identify specific behavior patterns that software development teams fall into. Perhaps the most familiar behavior pattern is flipping the “Bozo bit� � in other words writing someone off as not a valuable member on the team. Small nuggets of insight like this one are woven together into a tapestry of the behaviors you don’t want to see in your team.
June 4, 2008
For anyone involved in any capacity of a business that produces software, this is required reading. Filled with bits of wisdom and anecdotes regarding the life cycle of software development, there is something in here for everyone. The author's style is light and humorous (I caught myself laughing out loud at some sections), and that helps to give levity to a business that can take itself way too seriously.
February 21, 2009
Jim McCarty is a master at understanding software development and software teams.
Want to read
June 23, 2009this book recommended on Dec 2002 by Nick Seguin my SQL Server NH instructor. Jim McCarthy is Nick's "guru". anecdotal book about his personal experience.
Want to read
January 20, 2010The Pragmatic Programmer suggests this book for group communication.
February 17, 2014
Probably my third read, at least. A classic!
December 27, 2013
A lot of good material, but difficult to read. The names of the rules were also not clear and thus I will probably not use this book as a reference to go back and review things.
Displaying 1 - 15 of 15 reviews
Can't find what you're looking for?
Get help and learn more about the design.