Traditional software engineering deals with two phases of a product lifecycle: Development and Maintenance. In this short paper we propose to take a different approach and look at the product’s lifecycle using an analogy with the human lifecycle. We use this analogy to define roles that we call ‘research’, ‘engineering’, and ‘support’ to accommodate all the required activities that will keep a product useful for the longest period possible, while at the same time giving rapid response to customer needs.

1. From Lust to Dust: A Product’s Life Cycle
And the Roles that Make it All Worth It
Jorge Boria, M Eng
SEI Authorized Lead Appraisers, Liveware Inc.
jorge.boria@liveware.com
Abstract:
Traditional software engineering deals with two phases of a product lifecycle:
Development and Maintenance. In this short paper we propose to take a different
approach and look at the product’s lifecycle using an analogy with the human lifecycle.
We use this analogy to define roles that we call ‘research’, ‘engineering’, and ‘support’ to
accommodate all the required activities that will keep a product useful for the longest
period possible, while at the same time giving rapid response to customer needs..
Introduction
In his novel cum essay “Zen and the Art of Motorcycle Maintenance: An Inquiry into
Values” Robert Pirsig defines quality not as an attribute but as a relation between the
object in which quality is perceived and the person that perceives that quality. His point
is that quality is elusive even if so simple, because it is so personal. Perhaps we could
paraphrase the lyrics of ‘Happiness Is’ and say Quality is different things to different
people! Even if they are discussing the same object they might have a completely
different sense of its quality.
In an in-depth tutorial on agile processes held during SEPG 2001 in New Orleans, Brian
Nejmeh pointed out that our “one-size-fits-all” approach to strategy and processes does
not meet the needs of organizations. His thesis, based on “Crossing the Chasm” is that
at every stage of a product’s life different processes are required. For example, at Stage
1 innovation and speed are key elements to capture the innovators’ minds, therefore
“quality” in this stage is measured in the bells and whistles; but moving on to the next
stage entails a different approach, where quality switches from being measured in the
number and diversity of features to reliability and availability of the product. Further down
the lifecycle, support and maintenance activities are the paramount of quality. As the
product ages, the needs of the customer change too. Hence, if we can see how a
product ages throughout its life cycle and tie it to the emphasis on one or another type of
engineering, we will be better off in dealing with the product’s (and hence, the
customer’s) needs.
The product life cycle
If we break down the life cycle of a product from before its creation to the moment it is no
longer supported, drawing from our own (human) life cycle as an analogy, we have the
following stages:

2. 1: Pre-conceptual Stage
Before a product is even conceived, a number of influences are already in place to
support its launch into this world. We can distinguish amongst them environmental
conditions, external to the organization that will use the product, including technological
assets and market needs; internal conditions including training needs and cultural drives
that make the product concept acceptable, personal skills of individuals, managers and
line personnel, together with inclination to use the new system and a desire to achieve
better results through technology. All these forces start acting together until some formal
documents are assembled to start a project with the purpose of delivering a product.
This is the pre-conceptual stage of a product. The moment the formal documents that
define the product as a concept are created we call the conception moment.
2: Engineering Stage
Once the product is envisioned, many roads are possibly explored, both inside and
outside the organization, to help with its conception. In an ideal world, there should be a
defined instant in which a project is created (budgeted and staffed) to engineer the
product. We will call the time used in the execution of this project the engineering stage.
A well-defined engineering stage has a well-defined process to describe it. Engineering
is to a product like pre-natal stages are to a person: Everyone expects the newcomer, no
one is sure what it will look like, many expectations surround it, and it almost sure that it
is going to keep us sleepless for many weeks after it arrives!
3: Birth
The engineering stage ends in deployment, also called “cut over”. This is not a stage,
but an event. It is the “birth” of the product.
4: Deployment Stage
Once a product is deployed, it usually suffers from many problems due to the
dissonance between what was required and what was produced. This stage, of tentative
use, is very much like early childhood: the product does not stand on its own, it babbles
when it wants to speak, and, in general, has to be cleaned every few hours. Think of this
as the Beta phase of the software product, usually extended well into the user’s first
attempts to apply the product in a working environment.
5: Early Adoption Stage
If the product survives its childhood, the next stage is not nice, but definitely better: it
enters its inception stage, in which many things are overlooked with the expectancy that
they will be solved in the future. A product is usually in this stage during its first two
versions, which constantly act up, destroy your expectations, and need urgent corrective
measures. Inception is a lot like adolescence.

3. 6: Institutionalization Stage
As a product matures the users learn to trust it, and at one point it becomes
institutionalized into common use. The product has achieved, like some grown-ups,
maturity and reliability. During this stage most changes are enhancements that are not
difficult to implement and possibly some adjustments to environmental changes.
7: Decay Stage
The accumulation of changes over long periods of time, or new technological developments, finally take a toll on the design and the product ages rapidly. During the decay
stage, the product is progressively less reliable, it becomes harder and harder to
maintain, it cannot be adjusted to the new technology, and people tend to work around it,
instead of through it. Then, one day, someone pulls the plug and the product is gone,
possibly replaced by a newer one, which the demised one has partially supported during
its childhood. A pictorial view of the life cycle is presented in Figure 1.
Development Roles
The figure below depicts the relationship of customer needs to the engineering and
support environment. We prefer the names ‘engineering’ and ‘support’ to the traditional
‘development’ and ‘maintenance’, since we do not think of maintenance as a phase in
the development cycle, or as the environment that is created after delivery, which we call
support (the tiny arrows that show as quick fixes in the figure). Maintenance activities
take place either in the support environment or in a normal project environment.
We define maintenance here as the application to an existing product of any one of the
following four processes: “additions”, “fixes”, “adjustments”, or “migrations”. Additions are
extensions to the product. Fixes are changes done to the product to eliminate its defects.
Adjustments are changes done to the product to accommodate external changes (e.g.,
the basic tenets in the underlying discipline have changed.) Migrations are induced by
changes in the underlying technology platform. As a general rule, only fixes are done
during support, while for additions, adjustments, large clusters of fixes, and migrations,
new projects are created and they operate in the engineering mode. These activities are
therefore part of the normal development cycle for a subsequent version of a product
that has already been created. During the life cycle, the people that work with the
product operate in different “roles” to achieve their goals. We will use a model that
describes three different roles [Trab90].

4. Figure 1: Product Life Cycle vs. Project Life Cycle
Role 1: Research and Exploration
Ideas that end up in a product are often initially created by a group that is guided by
spontaneity and inspiration [Olso93]. This group works best following an evolutionary
model, that is, building bits and pieces and tying them together into a less than
completely coherent work product, often called a “proof of concept.” The emphasis of
such a group lies in innovation. Exploration (of new technologies and ways to apply it)
and redoing are encouraged. Control is lax, although these groups usually work under a
fixed budget. Whatever they turn out is usually well received. The goals are set in long
term visions. The costs incurred in research are sunken costs to the company, that is,
they are incurred without immediate accountability.
Role 2: Engineering
The economic viability of a software product lies in its quality and in its development
costs. If quality is low, the product is not viable (see role 3 for an explanation.) If the
development costs are too high, there might not be enough market to compensate these
costs. When people work in this role they should be less concerned about innovation
and more about quality. This role is best managed through a well defined process
model, in which a requirements-gathering phase precedes the design phase, that in turn
precedes the implementation phase. (Although this so-called “waterfall model” is strictly
sequential, it is seldom the case that the developers “run” the activities in such clear-cut
order. They usually go back and forth from requirements to design. They might even
move forward to implement a little, then back to gathering requirements. However, the
nature of each activity and where each belongs in a documentation scheme should be
kept clear at all times.) Exploration is discouraged and rework is considered a necessary
evil. Control is strict, and budgetary constraints are strongly tied to project management.
Goals are now midterm, counted in the order of months, not years. The costs of activities
performed in this role are fixed, but not sunken. A product is expected as an outcome,
and the costs of the product are indirectly (as we shall see when we look at Role 3)
dependent on the expenses of the phase.

5. Role 3: Quick Fixes
Under this role, only urgent patches are tackled. Larger fixes and enhancements are
then rewoven into the fabric of the product through newer versions developed in an
iteration of role 2 (version n, n>1.0). In role 3, the process changes to “fix and ship,” the
emphasis at this time residing in immediate response. Exploration and redoing are now
punished, because otherwise control is even less attainable. The lack of control tied to
this role is linked to the fact that the costs for the role are a function of the quality of the
product. Products with poor quality are harder to maintain and enhance, incrementing
the costs of repair. This is truly bad, since now these costs are variable costs, a function
of both the number of problems found during operation and the number of corresponding
calls received.
CHARACTERISTIC
Guiding Force
Personnel
Characteristics
Ruling Principles
Control
Costs
Working Paradigm
Outcome
RESEARCH AND
EXPLORATION
Spontaneity and
Inspiration
Creative (a solution in
search of a problem)
Individual exploration
Lax
Sunken
Evolutionary
Set of Inspirational
Ideas
ROLE
ENGINEERING
Quality and
Personal Pride
Problem Solver
(applied creativity)
Discipline
Strict
Fixed
Sequential or
Spiral
Product Version
IMPLEMENTATION
AND SUPPORT
Customer Satisfaction
Problem Patcher (on-thefly fixes)
Reaction Time
Very Lax
Variable
Patch’n’go
Customer Payments
Table 1: Different Characteristics in the Roles of Operation
This means that you have to set up a “project” approach for the engineering role, and
that what you have not included in the project you cannot do later, unless you start a
follow-up project (no quick fixes will help you.) This idea of follow-up projects to modify
the product so as to comply with a set of requested changes and enhancements is
central to a good maintenance structure. It is a big part of the solution, but not all of it. It
is called ‘versioning’ and it allows for very good management practices for updates and
fixes to the product. A simplified model of versioning can be stated as managing
requests for changes by classifying them into two categories: ‘Done Immediately’ (by the
‘support’ role) and ‘Will be part of the next version release’ (and you start a follow-up
project to do it, or incorporate the requirement to an existing project.)
Conclusions
Summing up, if you don’t have creativity (research), your product runs serious risk of not
having a market, but if you don’t have engineering, the risk is that the cost of dealing
with requests for changes from customers is going to be larger than your benefits. There
is very little you can do to remedy poor quality when you are working in role 3. If you

6. want to control maintenance and support costs, since they are the only variable costs in
all three modes, you must focus on the engineering role: Focus on quality increments
the fixed costs of that role, but lowers the variable costs of the support role. Counter
intuitively for some, focusing on quality will also help raise productivity, because it
eliminates costly rework.