Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Introduction to the 2006 Edition

Introduction to the 2006 Edition

Writing Dynamics of Software Development (Microsoft Press, 1995) was a task I found maddeningly difficult. As short a book as it was, the writing of it nonetheless seemed to take forever. I was scared to do it the whole time, uncertain if I could, and wondering if I even should. Historically, I presented much of the same material (when I presented it at all) in a talk. I was comfortable with that more immediate medium. After all, a talk or a speech was a highly focused, interactive burst of effort of short duration: a few hours of stress and I would be done. Moreover, much of my effort would be subsidized by my audience’s own efforts of attention; and the creative costs would be guided by immediate and ongoing feedback.

Throughout the process of writing Dynamics, I often found myself wishing I had decided instead to just publish a video. But, alas, for a variety of reasons, I had decided otherwise. The folks at Microsoft Press had supported me in that decision, and now I was obligated to actually deliver what I had promised to deliver to them. After many fits and starts, and after much avoidance and very elaborated excuses, and with a great deal of support from my future wife, Michele, I did eventually come—at long last—to the end of my writing effort.

As it happens, the final words I actually wrote for Dynamics ended up among the first to appear physically in the book. They are in the preface. The very last sentence I wrote for Dynamics was the following:

My hope, of course, is that Dynamics of Software Development contains threads that in later editions or further volumes can be woven into a more comprehensive tapestry.

The present revisiting of Dynamics therefore has two purposes. The first is contextual: fill in the picture, augment the original rules, and note the rules’ further evolution. The second and, I believe, higher purpose is to (at least) proclaim and (perhaps) to deliver the fulfillment of that hope articulated above.

This new edition of Dynamics contains three parts, which are quickly described here and then more fully described in the remainder of this Introduction.

Part I is the original text of the 1995 edition of the book.

Part II introduces to the Dynamics audience the system of interpersonal protocols and patterns called The Core. The Core embodies the results of our further living with and by the Dynamics’ rules of thumb in the decade since their initial publication. Also note we’ve added the following rules:

#55: Your boss is your best customer.

#56: Be a perfect boss.

#57: Pay the lumber tax.

Part III is a multimedia addition prepared exclusively for Dynamics (Round Two). We hereby offer on the enclosed CD:

  • The video of a 1995 talk, 23 ½ Rules of Thumb for Shipping Great Software on Time, which has, over time, engendered a widespread and enthusiastic following.

  • Four episodes of The McCarthy Show

As far as Part I goes, the original 1995 text remains—as it was in 1995—a stand-alone collection of short essays or rules of thumb, describing and/or based on the behavior of several related Microsoft software development sub-teams working together at the end of the pre-Web era. Over time, very few questions about the accuracy of the story have arisen. Nor have there been many credible challenges to the conclusions drawn, or convincing counter claims to the rules of thumb abstracted from the software development experiences under study. So we leave it as we found it, largely unchanged, generally accepted and acceptable. We are constraining our editorial urges therein to simply adding additional contextual information and pointing toward the further progress of the ideas.

As mentioned above, Dynamics had its origins in a talk I gave repeatedly in the 1990s, which became a bit of a performance piece over time. We are glad to provide the best recorded instance of this talk as a major and intrinsic part of this new edition of Dynamics of Software Development, on CD. The talk, in its turn, started out as a seminar given at software development conferences, the title of which was Slipping Without Falling. In that era, “slipping the schedule”—that is, failing to finish as planned—was the great unmentionable fact of software development. How to cope with the enormous uncertainty of software development scheduling was, though not largely discussed, the central problem of managing software projects. Accepting this as fact, and proclaiming its typicality was, I believe, the central innovation that provided both the appeal and the basis for the success of Dynamics. How to cope with a slip had never been mentioned and yet was the central activity in the trenches at software companies. Why an entire industry would avoid addressing the basic skill set required for success is an appealing question to the curious mind. Such wholesale self-destruction could not indefinitely go without remark.

I believe that the sheer audacity of addressing this reality was the principal attraction of the seminar. Over a period of about six or seven years Slipping Without Falling evolved into 21 Rules of Thumb for Shipping Great Software on Time. Numerous attendees of that seminar or listeners of that speech suggested that there ought to be a book. Microsoft Press was receptive to that idea and requested a summary of said speech which became the essay, 21 Rules of Thumb for Creating Great Software on Time. I wrote this essay, sent it to an MS Press editor and never thought of it again. Later I found out that this essay—to no one’s blame or credit—was passed around like some kind of Web samizdat. Even today, if you Google “21 Rules of Thumb” you will find thousands of references and links.

The 21 rules became 54 in order to create a whole book. That became Dynamics of Software Development, which is now intact in Part I of Dynamics of Software Development, 2006 edition.

In Part II of this edition, we attempt to show what we believe to be the more comprehensive tapestry originally hoped for (and diligently worked on) in the decade since Dynamics. We call this “tapestry” The Core. Like any ambitious software, however, the final form of said “tapestry” remains elusive. We have cross-referenced many of the ideas in Dynamics with our later work, especially The Core Protocols, to show the evolution of these ideas and the persistence of the original vision.

Persistence is something best understood in hindsight; in the moment, it often feels like folly and can be readily mistaken for mule-headed stubbornness. Nonetheless, during these years I have often thought of the hope first articulated at the beginning of Dynamics with increasing faith that we were indeed fulfilling that promise.

As I concluded the writing of Dynamics in 1995, I was ably assisted by Michele Frame, a model program manager at Microsoft. Her support of those ideas at that time provided the necessary impetus to get me into ship mode on the book. Shortly after publication we left Microsoft together to pursue, in a more aggressive and sustained way, the experimental approach that would yield our “more comprehensive tapestry.”

Together we realized that software development, per se, was really just a case study of human collaboration and that if we could establish a means by which any group could reliably attain a state of shared vision, we would have tamed the beast, stitched together our threads, and civilized our world. Unfortunately there was no way to do this quickly enough in the corporate environment. There is no way any software manager or any software team could, in a single lifetime, conduct enough development cycles with sufficient experimentation to ever figure this out.

We began to simulate development cycles with real-world teams in a one week course we called BootCamp. And even though we had our pile of “threads” we could teach the campers, we really needed them to work on the problem of developing a single repeatable process that would always yield a successful team in a state of shared vision. And so, enhancing our reputation for audacity, we simply assigned it to the teams that would come in: “Design, implement, and deliver a course that teaches you everything you need to know to ship great software on time, every time.”

This was the product that our teams in simulation had to create in a week. This made for a very lively week because if they failed to deliver, it could be argued they failed the course. This assignment has never varied in any significant way over the last decade and each time the course was conducted (and hence created) more “best practices” for collaboration emerged. We abstracted them from the often chaotic efforts of each team, experimented with them on our own teams in the intervals between BootCamps, and handed them on to the next team as a starting point.

In a sort of miracle of symmetry it became clear to us that the solution to software development and other complex collaborative efforts was (in fact) a new kind of software: interpersonal protocols, definitions and patterns coded up, standardized, de-personalized and versioned, which we named The Core Protocols.

It probably should not have been surprising to us that real dynamics of software development would ultimately yield software, but it was. This software and its use is the context of Part II. The details of Version 1.0 of The Core Protocols and its surrounding ideas and history are contained in Software for Your Head, (Addison-Wesley, 2002).

Published in this book for the first time is Version 3.0 of The Core Protocols.

We are confident that you can see the outlines (at least) of our hoped-for tapestry. It is our continued ambition that further versions of this work will yield a more vivid, beautiful, and useful tapestry.

Jim McCarthy and Michele McCarthy

July, 2006

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint