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.
- 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
- 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
- Pick some metrics and report them regularly. Bug arrivals, bug fixes, "churn"
(daily #lines of change in source code), whatever, but report regularly.
- 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.
- 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.)
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.
Could use some editing and reorganization; the above summary localizes relevant
messages much better than the text does.
Back to index