The Communications Web site, http://cacm.acm.org,
features more than a dozen bloggers in the BloG@cAcm
community. in each issue of Communications, we’ll publish
excerpts from selected posts.
follow us on Twitter at http://twitter.com/blogcAcm
Health systems, and
Greg Linden writes about frequent software deployments, Ruben
Ortega reports on smartphones and health systems research, and
Jason Hong discusses designing effective security warnings.
from Greg linden’s “frequent Releases change software ngineering” Software release cycles are usually long, mea- sured in months, sometimes in years. Each of the stages—requirements,
design, development, and testing—
Recently, some of the constraints on
software deployment have changed. In
Web software, deployment is to your
own servers, nearly immediate and
highly reliable. On the desktop, many
of our applications routinely check for
updates on each use and patch themselves. It no longer is the case that getting out new software to people is slow
and inconsistent. The likelihood of a
reliable, fast Internet connection on
most machines has made it possible to
deploy software frequently.
But just because a thing is possible
does not mean it is desirable. Why
would we want to deploy software more
frequently? Is it not better to be careful,
slow, and deliberate about change?
The main reason to consider frequent deployments is not the direct
impact of getting software out to customers more quickly, but the indirect
impact internally. Frequent releases
force changes in how an organization
develops software. These changes ultimately reduce risk, speed development, and improve the product.
For example, consider what is required to deploy software multiple
times per day. First, you need to build
new deployment tools that are capable
of rapidly pushing out new software, can
handle thousands of potential versions
and enforce consistency, and allow rapid rollbacks in case of problems.
Software development has to
change. With multiple near-simultane-ous rollouts, no guarantee of synchronous deployment, and no coordination
possible with other changes, all soft-
ware changes have to be independent
and backward-compatible. The software must always evolve.
Requirements, design, and testing
can be shortened and replaced with
online experimentation. To learn more
about customer requirements and design preferences, deploy to a small set
of customers, test against a larger control group, and get real data on what
people want. Bugs are expected and
managed as a risk through small deployments, partial deployments, and
Compare this to a more traditional
development process. Requirements
gathering and design are based on
small user studies and little data. Software is developed without concern
about backward compatibility and
must be rolled out synchronously with
many other changes. Testing has the
goal of eliminating bugs—not merely
managing risk—and is lengthy and expensive. When the software does roll
out, we inevitably find errors in requirements, design, and testing, but the organization has no inherent capacity
to respond by rapidly rolling back the
problems or rolling out fixes.
Frequent releases are desirable because of the changes it forces in software engineering. It discourages risky,
expensive, large projects. It encourages
experimentation, innovation, and rapid
iteration. It reduces the cost of failure
while also minimizing the risk of failure. It is a better way to build software.
The constraints on software deployment have changed. Our old assumptions on the cost, consistency, and