Back to index

Dynamics of Software Development

Jim McCarthy, Microsoft Visual C++

One-line summary: Managing software development is about managing people. Various hints for planning, developing, selling, and managing the people effectively. Although written from the perspective of a project manager charged with shipping and selling a product, many of the insights apply at least as well to research projects, and are more profound than the book's cheesy packaging suggests.

Overview/Main Points

• Stages of development: opening game (marketing strategy, identifing customer needs, etc.); middle game (development/debugging); ship mode (all-out race to get out the door). This last "Death March to Egghead" is the only way software ever ships.
• Proposed division of primary ownership:
  • program mgmt: scheduling, external dependencies, logistics
  • quality assurance: continuous monitoring of the state of the software
  • development: technical design/execution lead
  • product mgmt/mktg: messages to customers, launch logistics
  • documentation/user education
  • Rules of thumb: two developers for each person thinking about the software. One QA, one doc, 1/3 program manager per two developers.
  • "scout": clever person sent out to assess technology trends, etc. to "scout out" the vision for the next release or product. Visit customers, get trained on competitive technologies, etc. (Ed.: this sounds like the job I want!)
• Some things that have bit the author on the butt personally:
  • Lack of early establishment of shared vision
  • Persistent self-delusion about how much work could be done given present resources
  • Lack of attention to specific customer feedback
  • Lack of encouragement of continuous stream of ideas from all participants, and both the tecnical and psychological "goodness" they bring
• All about software features.
  • Strategic features: necessary to compete at all.
  • Competitive features: trump the competition.
  • Customer satisfaction features: in response to specific suggestions.
  • Investment features: return will show up in future release.
  • Paradigmatic features: change the way people work. These can make a killer app and steamroll competitors.
• Ode to feature teams:
  • provide empowerment, accountability, and identity with a piece of the software, consensus, balance in skills (Ed.: vertical responsibility), i.e. each team has developers, QA, marketing, etc. Corollary: If you don't understand something about the structure of the software, examine the team interactions.
  • (Ed. note: Without coherent guiding vision and architecture, feature teams can lead to chaotic software without unifying architecture. )
  • Feature teams don't evolve/take off until repeated failures make opportunities for bonding within the team evident.
  • Note that the concept of feature teams is in conflict with the (traditional) concept of "functional area" managers, as those managers' roles with respect to software features become indistinct, while their role with respect to "people management" grows in importance.
  • Corollary: the degree to which an individual from a particular discipline will participate successfully in a feature team is inversely proportional to their success under the "old regime".
• Happiness in software development.
  • Don't flip the bozo bit: if someone says something that sounds stupid, listen first to what they have to say before tuning them out for all time. "Make sure some primitive territorial instinct isn't clouding your judgment."
  • Don't try to achieve stability; instead learn to manage technology in motion. "If you don't persistently muster the courage and skill to undermine and supplant your own current technology . . . someone else will seize the historical moment." Voila Spyglass.
  • Empowerment is about enabling people to do their best, which is different from enabling them to do what they think best. Corollary: don't impose deadlines; instead let inter-group dependencies be the deadlines. Corollary: "lone programmers" are more likely to give you a headache than to help you.
  • Teamwork to slay the competition: "The word 'teamwork' suggests to many a touchy-feely, weak-kneed benevolence and inefficacious good will, but teamwork is really exemplified by the image of a vicious pack of snarling wolves cornering a young lamb. The remorseless wolves move in and make the kill with exquisitely timed moves, in a horrifying ballet of conquest."
  • Team meetings: the tone (subtext) of the meeting is at least as important as the content. It can either communicate "this is important and we need to pull together", or "this is mandated from above".
  • The things you think you understand, but really don't, are the ones that come back to haunt you.
  • Pick some metrics and report them regularly. Bug arrivals, bug fixes, "churn" (daily #lines of change in source code), whatever, but report regularly.
• Milestones:
  • Milestones give you the opportunity to "practice shipping" at intermediate dates not more than months apart. Status reports keep things from "going dark". (Ideally, weekly or so.) Regular complete builds add assurance.
  • Use ZD milestones: at milestone date, no new development allowed till milestone goal met with zero defects.
  • Possible milestones: "dogfooding" (eating your own dogfood); internal customer release; feature complete, UI freeze; friendly external customers.
  • If you miss a milestone, do a no-blame postmortem. Slips are inevitable consequences of intellectual-property development. "Slipping isn't the problem; being surprised by slipping is the problem." Resist the temptation to attempt to localize the slip cause to a single person or group if a "group dynamics" explanation is more likely. Sometimes a deliberate small slip is optimum.
  • After a slip, hit the next milestone no matter what, to restore morale. If necessary, make the milestone conservative.
• Staying ahead:
  • Someone is going to beat you. Who? How? When?
  • Invest more in paradigm-shifting features. Compete with yourself.
  • Set the pace of change beyond the reach of competitors. (Voila Netscape.)
  • Take big and ineradicable risks to settle new territory.
• Selling:
  • Stages of customer interest: Attentive; interested; convinced; desire. Only the last is a sale. To make the first means you must identify customer needs up front. You want even the most naive user to name one or two qualities that make the technology/product synonymous with your offering.
  • Ask your teams what user input they'd like. If they say 'none', find out why they're so lethargic. Real goal is to inculcate this thinking in your team.
  • Pursue the anomalies in your findings. If 10% of customers have switched to a new technology but 80% say they are planning to, what's holding them back?
  • "Find out what customers are struggling with, then turn everything in that direction." Example: Microsoft Wizards (ugh) hit a market sweet spot, because configuration etc. was reported by customers to be difficult and unpleasant. Example: customer feedback indicated that a common case for spreadsheets was typing in a few numbers and instantly converting it into a chart; this was put into Excel, and for many customers that single feature justified the purchase.
  • Corollary: Be single minded. Pick a theme, focus the product around it, turn it into a sound bite if necessary. Example: Microsoft surveys found that customers who hadn't yet switched to C++ were being restrained by the learning curve. Message: "Visual C++ makes it easy to get started with C++." Duh.
• Ship mode:
  • Beta is not the time for change, but rather for "spin development".
  • Do aggressive bug triage.
  • Instill a horror of changing the product during beta.
  • Launch is not just marketing, it's fervent evangelism. Everyone should be participating to some extent. If they don't naturally do so by now, you've failed to instill the vision (or you've hired the wrong people).
  • Hire superstars. Look for the ineffable "spark of intelligence." Remember racehorses have to run. Overreachers should have their energy channeled to useful goals, rather than spreading themselves too thin. (Ed. note: also have someone else do the prescreening. Look for people who are tops in some class, or have some outstanding distinction you can calibrate against, etc.)

Relevance

This is research. Software development and shipping is what we do, at least if we want the research to have an impact during our lifetime.

Flaws

Could use some editing and reorganization; the above summary localizes relevant messages much better than the text does.

Back to index