Dynamics of Software Development: Rules to ship by

In this month's Classic Bookshelf, Lamont Adams takes a look at Jim McCarthy's 54 rules of delivering great software on time. Don't flip your Bozo bit--read the article!

In this month’s Classic Bookshelf, I’ll be looking at Dynamics of Software Development (Jim McCarthy, $19.95, Microsoft Press, 1995), which is the book form of Jim McCarthy’s 54 “rules” for how to “deliver great software on time.” These rules express McCarthy’s philosophy on project management, team building, software development, and marketing.

So what makes this a classic book? It is barely six years old, after all. I’ll give you two reasons. First, the rules and advice to be found here are excellent. Although McCarthy generally concentrates on development of commercial, packaged software, his rules are almost without exception applicable to any software development effort. Second, Dynamics offers a fascinating window into the corporate culture at Microsoft in the early 1990s, just before the company reached the height of its power.

Who the heck is Jim McCarthy?
Jim McCarthy is the former director of the Microsoft Visual C++ Program Management team and struck me as quite an esoteric character when I met him at the 1999 VBITS conference in Chicago. One of the sidebars early in the book serves as McCarthy’s resume; it explains why he feels he’s qualified to tell the reader about software development. The story goes like this:

Way back in 1992, Microsoft’s competitor in the development tool space (obviously, this is Borland, but McCarthy never comes out and says so) is out-competing Microsoft very handily. Microsoft’s latest tool release, C7, is essentially a flop. Industry observers are suggesting that Microsoft get out of the language business altogether and concentrate on applications. It is in this environment that McCarthy is made coleader, along with Denis Gilbert (who wrote the foreword to Dynamics) of the disorganized, demoralized Languages Business Unit. He is given an extremely ambitious timetable for a then-nebulous project code-named “Caviar” (Visual C++ 1.0) and told to sink or swim. McCarthy goes on to relate how his team managed to get Caviar into development, published, and shipped so quickly that he not only beat the deadline set for the project but also, in his own words, “caught the competition flat-footed.”

The “rules”
McCarthy’s experiences during this time provide the basis for the rules he relays in Dynamics. Each rule is really a short essay or personal anecdote from Caviar’s development. The rules, and the resulting book, are divided into four loose categories, each representing a different stage in the development process.

“Opening Moves,” the longest section of the book, lays out a groundwork for facilitating and managing the design process, fighting burnout, and building a team out of a group of developers and their ancillary groups. Here, we learn about McCarthy’s favored management strategy of empowered consensus. He defines the role of a software manager as helping to create a “shared vision” for the software. Once created, the manager should keep this vision safe and guard it for, or sometimes against, the team. McCarthy also talks about sizing up your competitors and scouting out your market, and he shares a lot about Microsoft’s marketing philosophy and how it figures prominently into everything the company does.

The other sections are considerably shorter than the first. “The Middle Game” covers the actual development process and relates McCarthy’s rules for measuring progress and keeping the team focused and productive. “Ship Mode” offers wisdom on refining software until it reaches the goals set for it during the opening moves and explains how to tell when it has reached a goal. Finally, in the “Launch” section, McCarthy provides advice on what to do when we do reach our goals, when the product is finished, and when we're ready to ship the software.

Dynamics also includes an appendix with the author’s advice on finding, hiring, and keeping good people for your development organization. He suggests that you look for an “ineffable spark of intelligence” in a candidate and that you give that person a puzzle of some kind to solve. To retain good, creative people, he says that you must keep them challenged, give them “someplace to run," and support their creative endeavors whenever possible.

My favorites
Here are some of my favorite rules, culled from various parts of the book:

#4 Don’t flip the bozo bit, which is basically an admonishment to never assume that someone is an idiot—and to not play the fool yourself, lest someone else flip your bozo bit.

#18 Cycle Rapidly, which is Microsoft’s marketing philosophy in a nutshell. Overwhelm your competitors and impress your customers with the rapidity of your new releases, each chockful of new features.

#21 Minimize Dependencies. A dependency is anything not under your direct control. They should be kept to a minimum, as they can potentially cause serious problems later in the process.

#30 Don’t go dark or, in other words, don’t be out of communication for long. Have as short a period as possible between deliverable due dates, even if this means shrinking the size or scope of your deliverables. Too long a period and you run the risk of going dark and suffering a serious schedule slip.

#51 Triage Ruthlessly to determine whether a defect is severe enough to keep the software from being considered complete and distributable. Organize and prioritize bugs according to severity, significance, extent of occurrence, the potential that fixing them will destabilize something else, and team resource availability.

Unfortunately, McCarthy occasionally winds up on a soapbox, seeming self-serving or arrogant. Usually this happens in sidebars, like the rambling “A story from close to home.” In fact, there are so many sidebars of varying quality scattered throughout the book that I wonder if the publisher avoided cutting some of them simply to make the book—which is an admittedly short 184 pages—stand a little thicker on the shelf. Usually, however, McCarthy, writing in a rich, informal style, stays on topic with dynamite project management advice for the reader. On the strength of the 54 “rules” and the advice they offer, this is an excellent book and worth a read by developers and management-types alike.

Editor's Picks