figure 1. Linear completion.
Quantity of Product
use of Resources (time, effort)
figure 2. Rayleigh Curve.
Percentage of total effort
y = 2 Kate -at2
K = total Effort
a = constant
t = time
figure 3. Cumulative Completion.
tinct stages and they apply as much to
painting a room as they might to building software.
Preparation. The environment must
be prepared before work can commence. For software this means setting
up servers and version control systems,
acquiring tools, planning and estimating, sourcing staff and other essential
activities that take time but might not
actually create much in the way of software product. When painting a room,
we have to choose the color scheme,
measure, tape up the woodwork, and
buy the paint, all before we can start
putting it on the wall.
Production is the steepest slope
where the maximum rate of measurable work occurs—the most code is
written, the most paint is applied.
Proving is the final long tail of the
process. In software it is completing the
exception code (the mainline code was
done in production), testing it to prove
it works and fixing it when it does not.
This always seems to take longer than
it should partly because we invariably
find out things we were not expecting—
which is where the Second Order Ignorance comes in. In painting, this is the
detail work, the tricky corners and, of
course, the cleanup—which also always
seems to take longer than it should.
y = K ( 1 - e -at2 )
things in systems development can be
described by a Rayleigh Curve3, 4 (see
Figure 2). This curve shows the amount
of work that can be done varies with
time. It rises from zero to a peak, perhaps a third of the way into the activity,
and then drops off back to zero. The cumulative version of this curve is shown
in Figure 3.
Non-Linear. If we compare Figure
3 with Figure 1 we notice the cumula-
tive curve relationship of percentage
of product complete and percentage of
resource used (time in this case) is not
a straight line. Some percentage on one
axis does not mean the same percentage
on the other. In fact, in Figure 3, when
the product is 90% complete, the activi-
ty is only about halfway through its total
time. This is partly where the miscalcu-
lation of progress comes from. If devel-
opers or project managers, consciously
or unconsciously, apply a mental model
that is linear to something that behaves
non-linearly it is not surprising that
they incorrectly assess progress.
There are many reasons why people
overreport progress: optimism, pride,
pressure to show results, inexperience,
poor resource allocation, even how
they are compensated, and they all play
a part in overstating development and
underestimating the remaining work.
But realizing that we cannot calculate exactly how far we have left to go
because we do not know exactly where
we are going and simply using the correct mathematical model of progress
would certainly help.
1. armour, P.G. the Five Orders of Ignorance. Commun.
ACM 43, 10 (Oct. 2000), 17.
2. deMarco, t. Why Does Software Cost So Much? dorset
House, 1995, 4.
3. norden, P.V. On the anatomy of development projects.
IRE Trans. Eng. Management 7, 1 (1960), 40.
4. Putnam, l.H., and Myers, W. Measures for Excellence.
yourdon Press, 1992, 46.
This model also makes intuitive sense.
In Figure 3, the curve has three dis-
Phillip G. Armour ( firstname.lastname@example.org) is a senior
consultant at Corvus International Inc., deer Park, Il,
and a principal consultant at QsM Inc., Mclean, Va.
Copyright held by author.