Best Practices
IEEE Software, Vol. 14, No. 1, January/February 1997
Annualized Software Delivery
Projects in the commercial software industry are often characterized by
frenzied attempts to leapfrog the competition. Companies try to deliver
innovative products in short time frames, and in their ill-fated attempts to
serve two masters, development time and product innovation both suffer. A
history of the GigaCorp company, a composite of companies I have worked
with, describes the situation in more detail.
GigaCorp produced a successful widget formatter called GigaMat 1.0. It was
well-received in the marketplace and offered significantly more
functionality than its main competitor, MegaMat. A few months after GigaMat
was released, MegaCorp, released a new version of MegaMat, which provided
incrementally more functionality than GigaMat 1.0.
Because of the competitive situation, GigaCorp then set a target of
releasing a minor upgrade, GigaMat 1.2, within 3 months. The project
planners recognized that 3 months was an ambitious schedule but felt that to
remain competitive they had no other choice.
As a result of the short schedule, the GigaMat 1.2 team rushed through the
early stages of analysis and design--doing little requirements analysis and
virtually no design. In the later stages of the project, it found that some
of its assumptions about the product's requirements were invalid, and the
team then spent a great deal of time correcting defects that it had inserted
during the requirements and design stages.
Although it developed an initial implementation of the intended
functionality within the desired 3 month time frame, the quality of the
product was poor enough that it could not be released to the public. The
GigaMat 1.2 project then spent months in an extended integration, test, and
defect-correction cycle, and finally released the product after 12 months.
In later versions of GigaMat, the code base became extremely brittle. Even
minor changes became time-consuming and error prone. Time that might have
been spent developing innovative new capabilities was instead spent
correcting the problems arising from incomplete design, rushed
implementation, and short-term planning decisions that had been made in
earlier releases.
The pattern at GigaCorp isn't unusual. Companies create products under
intense schedule pressure, which produces low quality design and code bases.
A company typically knows that its product is built on a shaky foundation,
but because of pressure to release timely upgrades, it continues to extend
its low-quality code base in hopes of delivering the next version as quickly
as possible. As problems mount, the company realizes that the notion of
using a poor quality code base to support quick development is a cruel
joke--it severely hobbles the company's ability to extend its product and
ultimately delays delivery.
A Two-Part Plan
Annualized releases provide a means of escaping from pressure-cooker
upgrade cycles and low-quality code bases. Suppose you work for the GigaCorp
company and that you released the first version of your GigaMat widget
formatter in 1996. With annualized delivery, you can strategically divide
your future development efforts into two parts, which provide for
incremental releases in 1997, 1998, and 1999 and a completely redesigned
product in 2000.
Part 1: Incremental Enhancement
One team maintains and enhances the product thread that started with
GigaMat 1996 and that will continue through 1999. It is tasked to deliver
minor, incremental improvements that can readily be supported by the
existing code base.
This team is committed to release incremental updates approximately once a
year. Functionality is developed in increments, perhaps using daily builds
to drive to a potentially shippable state once every two months or so.
Keeping the product close to a shippable state at all times increases the
likelihood of actually shipping the product close to its target delivery
date.
Part 2: New Development
While the first team delivers incremental improvements, a second team
develops a completely new GigaMat 2000 that sheds much of the baggage
associated with GigaMat 1996. This team is tasked to make wholesale
conceptual improvements in both the product and its underlying design and
implementation.
Separating the new development effort from the enhancement effort allows
this team to focus on the job of innovating without being preoccupied with
short-term delivery pressures. Because of the longer time frame, it can
treat the development of a new GigaMat 2000 as a truly innovative exercise
in redefining the state of the art in its product area.
More effective development. For all but the richest
companies, the major objection to this strategy will be that it is
prohibitively expensive to conduct two separate development threads. But
this strategy is much less expensive than it might at first appear because
separating development into two branches allows each branch to operate more
efficiently.
For new development, the current crash-development style leads to poor
designs, poor implementation, poor quality, excessive rework, developer
burnout, high turnover--in short, to significant inefficiencies. Development
takes place in a pressure cooker, hardly the ideal environment for creating
innovative products. By stretching out the development cycle,
product-redesign can be conducted at a more leisurely, contemplative,
innovative pace with a smaller staff. The smaller staff can operate more
efficiently, and product integrity is likely to benefit.
Having an independent product-redesign underway reduces the enhancement
team's need to leapfrog the competition with each release. Cramming major
new functinoality into an incremental release increases the risk of late
delivery. When incremental enhancements are separated from new development,
you can instead plan an enhancement release as a strategic, low-risk effort
to provide timely, incremental improvements to your customers.
More proactive improvements in strategic assets.
Currently, most companies will create a new code base only after their old
code base has become so brittle that it is virtually impossible to maintain.
This puts a company in a reactive posture rather than a proactive one, and
virtually guarantees that the last development cycle that uses the old code
base will be characterized by enormous struggles to make even the tiniest
improvements in the outdated design and code.
The annualized delivery strategy accounts for the reality that most code
bases deteriorate under maintenance--especially if major portions of the
code base were originally developed under intense schedule pressure. The
strategy puts a company on track to renew the code base for a strategic
product every few years, proactively, before the old code base becomes
unmaintainable and sabotages new development efforts.
More regular product releases. From a software purchaser's
point of view, software products are currently delivered at irregular
intervals, perhaps as infrequently as every two or three years. Although
software vendors continue to make more ambitious schedule promises, the
commercial software industry's track record does not instill much
confidence. Because of uncertainty in product-release cycles, a
software-using company doesn't know whether to budget for a product upgrade
this year, next year, or the year after that. Software vendors thus fail to
provide the support needed for mid- to long-range planning.
With annualized releases, software-using companies can decide once a year
whether to upgrade. Planning uncertainty is reduced. Annualized releases
reduce the planning risks that now arise from companies that announce
release dates they have no reasonable chance of meeting.
Less baggage for established companies. One of the nagging
problems in the commercial software industry has been how a company with a
large installed base can enhance its products with the same agility that a
startup company can. The obligation to support an existing customer base can
become a ball and chain that restricts an established company's ability to
innovate.
Annualized product releases allow an established company to recapture some
of the startup company's agility. An established company can announce a
policy like this: "We guarantee that we will support the 1996 model of
GigaMat in enhancement releases through the year 1999. After that, we will
introduce a redesigned GigaMat 2000, which will not support an upgrade path
from previous versions." Each customer will have to decide whether to
upgrade to GigaMat 2000 or continue using GigaMat 1999. This approach shifts
part of the responsibility for staying with an outdated product back onto
customer's shoulders, and since three to five years is a lifetime in the
computer industry, limiting upgrade support to that time frame seems
inherently reasonable.
We Rejoin This Program Already in Progress...
Certain segments of the commercial software industry are already using
forms of annualized product releases. Tax programs such as Turbo Tax have,
of necessity, been on annualized release cycles since their inception.
Multi-media titles such as Encarta joined the annualized release bandwagon
later. Time will tell whether product names such as "Windows 95" and "Office
97" are driven by an annual release strategy.
The broader commercial software industry needs to recognize that
significant upgrades of major products typically take an amount of time
measured in years rather than weeks or months. If a company is able to step
back from the current frenzy of new-product development and invest the time
needed to develop a truly innovative product, it should be able to deliver
products that are so well designed and implemented that they can remain
popular and competitive for three to five years--which will provide enough
time to complete the next innovative design cycle.
Editor: Steve McConnell, Construx Software, 11820 Northup
Way
#E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
