Communications - January 2010

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
DOI: 10.1145/1629175.1629181
http://cacm.acm.org/blogs/blog-cacm
software engineering,
smartphones and
Health systems, and
security Warnings
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— takes time.

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 rapid rollbacks.

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.