http://xp123.com/xplor/xp0009b/index.shtml
1 of 7
2008-04-14 20:58
XPlorations
Economics of XP
September, 2000
Value and Cost
When you pay for something - including software - you are concerned about value and cost:
"What's it going to do for me?" and "How much will it cost?"
A software team delivers features over time. It takes a little time to get started, then the
highest-value features arrive, then less valuable features, until it's hard to add any more. You can
visualize this either as value at any time, or cumulative value:
We can consider cost as well. Suppose we have a base investment, then spend at a constant rate.
(The real world is more complex, but this is a useful approximation.)
The picture is most interesting when you superimpose the two "cumulative" curves:
(The "breakeven point" is where the positive territory finally starts to outweigh the negative.)
http://xp123.com/xplor/xp0009b/index.shtml
2 of 7
2008-04-14 20:58
This diagram shows the problem from the buyer's point of view: they have to invest for a while
(negative territory) in the hopes of a return, but eventually the system "wears out". The "+" area
minus the "-" area tells the net value we expect.
There are other possibilities: if the "+" area is less than the "-" area, we see something that never
returns a profit. Alternatively, if the value curve goes above the cost curve right away, you have
an easy call: you invest almost nothing, but you get immediate benefits ("low hanging fruit").
Finally, you might have a value curve that never arises above the cost curve. That tells us the
project is not worth it - it will always lose money.
Unfortunately, it's hard to know which situation pertains. The costs and benefits are almost never
a sure thing. It can be hard to assess when to give up on a project - there's always the hope that it
will turn around.
To improve our payback, we can either improve costs or improve value. Could we make a lower
initial investment, or a slower spending rate for the same value? Could we shift the value curve
left (perhaps steeper) - an earlier payback? Could we make the value curve higher - a larger total
payback for the investment?
Cost of Money
Money is expensive. (You've probably noticed this already.) Specifically, money we want to
invest has a cost.
Why should someone invest $1M on a software project that returns $1.001M, if they could earn
$1.1M from simple investments? An investor will demand a minimum return.
A dollar given to you this year is worth more than a dollar given to you three years from now, and
an investor will take that into account. The easiest way to think of this effect is as a discount on
the value curve - sort of an interest payment. And like your mortgage, you have to pay interest on
the interest, and so on. Thus, money has an exponentially growing cost. This discounting process
is known as net present value.
This effect tells you why business plans always seem to have a "hockey stick" graph for return on
investment. If they didn't, they'd never be able to pay back the "interest" on all that early money.
How does XP help?
To increase your net value, you've got to lower costs, increase payback, or both.
Several characteristics of XP help lower costs:
Small team size
Shared workspace at a single location
Lightweight tools
Synergy of practices
XP tends to use small teams. In The Mythical Man-Month, Brooks has a curve showing
communication costs. He makes the point that a large team may spend so much in
communication costs that they produce less than a smaller team. XP has found that a team of
about 10 people is a good size. If a team of 10 is as effective as a team of 30, they come at 1/3 the
cost.
http://xp123.com/xplor/xp0009b/index.shtml
3 of 7
2008-04-14 20:58
XP puts customers and programmers in one place. You don't have to worry about teams in two
separate locations - there's only one office to set up. You don't need to use special phones, video
facilities, or special software, and you don't have to pay for travel between offices.
XP tends to eschew tools like round-trip UML diagramming environments and
Gantt/PERT/Project-Management tools. Instead, it works with 3x5 index cards. Saving $1000 or
more a seat can let you buy a lot of file cards.
XP's practices work together in synergy, to get a team moving as quickly as possible to deliver
value the customer wants. By delivering faster, the same results cost less.
A second way to increase return is to change the value curve:
Shift it left: find a way to deliver the same value more quickly.
Shift it up: find a way to deliver more total value.
Shift the slope: find a way to deliver most of the value more quickly.
XP uses the planning game to maximize value delivered at any time. A "normal" development
team will deliver some things the customer needs today, along with some things they anticipate
the customer will need in the future. The latter is unduly expensive - because the customer doesn't
need it yet but has to pay for it now. In XP, the planning game identifies what's most important to
the customer, and has the team work on that right away. Thus, the higher-value returns are
front-loaded, so the team can move into the "+" area more quickly.
XP attempts to "lock in" the value it claims. "Normal" development can go a long time between
releases, and before being tested; there's always a doubt as to whether the system is truly ready
just because it's being designed and coded. XP uses small, frequent releases (along with
continuous integration and testing) to ensure the value really exists. The team can stop
development at any time, and what's done really works.
Frequent releases do something else as well: they put the system in the hands of users. Part of a
team's job is learning; this provides the feedback loop. This feedback can set up a virtuous cycle
where the team is better and better about delivering just what is needed.
How do you maximize delivered value?
Suppose you have a valuable feature that will take 3 weeks to implement, and a couple less
valuable ones that will take 1 and 2 days respectively. What do you do? Do you knock off the
easy ones to demonstrate progress, or do you tackle the most important thing first?
Recognize a subtlety here: the customer is not just saying, "This feature is more valuable" but
"Even at this cost, this feature is more valuable."
What if the big feature is the risky one? What if the project might be canceled after 3 weeks?
It can be hard to see things framed as software features. Instead, consider a money game. There
are four bills on the table: $50, $20, $10, and $2. You'll play a series of turns. In each turn, you'll
select a bill to add to your pile, and then you'll be given as much money as you have (doubling it).
The goal is to maximize your money.
So, if on the first turn you select the $10 bill, you'll have $20 at the end of turn 1. If you then
select the $2 bill, you'll have $44 at the end of turn 2. If you had selected them in the opposite
order, you'd have $28.
http://xp123.com/xplor/xp0009b/index.shtml
4 of 7
2008-04-14 20:58
What's your best strategy? It's pretty clear that you want to be greedy, working from the biggest
value to the smallest.
When we develop software, why do we feel the tug of doing the easier but less valuable things
first? I think it's because we like to get tasks done - we count tasks instead of value. (How often
do you see a feature list organized to tell value as well as cost?) We typically have little or no
feedback on value, so we count tasks. "Shortest Job First" is a strategy for maximizing the
number of tasks completed over time.
The issue is not all psychology about "getting things done" though. There are two problems: How
do you know which features are valuable? Can you implement them in that order?
XP has an easy answer to the first question: use the planning game to let the customer identify the
most valuable features, then implement in order of decreasing value.
The second question is trickier. Unfortunately, the answer is "no" - you can't always implement in
decreasing order:
Feature
Whiz-bang word processor
Development environment
Cost Value
$1M $2M
$1000 $500
If we don't have a development environment, we won't get a word processor.
Thus, dependencies exist, and more-valuable features can depend on less-valuable features.
XP's experience is that most dependences in software development can be identified and
eliminated early in development.
Since you can't escape the dependencies, you're better off the more you can eliminate early. Many
come early on: we have to choose an architecture, programming language, database, tools,
development environment, etc.
XP Strategy:
During release planning, do spikes on the biggest areas of risk.
During the first iteration, ensure that all pieces of your architecture are in place, even if
they have minimal implementations.
Establish and maintain a flexible design.
The Option to Cut and Run
By providing frequent releases, tested so we know that the software delivers what it claims, XP
has another advantage: at any point, we can suspend development and exploit what we already
have done.
A project not delivering frequently has a major risk: in the end, it might not work at all. It's very
hard to assess the value of a design. It's much easier to assess the value of a delivered system: we
can see what it really does, and what its quality level is.
I'm sure others have had the same experience I have: a room full of people has reviewed a design
document, had a meeting to discuss it, and then seen some unexpected problem during
http://xp123.com/xplor/xp0009b/index.shtml
5 of 7
2008-04-14 20:58
development that demonstrates that the design is completely wrong.
If software can demonstrate its value only by being tested and delivered, frequent releases provide
us a new opportunity: the option to cut and run. The customer has requested the most valuable
features first, and the system is ready to run. They can stop investing and collect the value:
Or, they can authorize another investment:
By making a series of investments, they'll match the overall value curve:
In buying the most valuable feature at each point along the way, we'd like to think our software is
at least as valuable as software produced by a process that's already wasted time on less important
features.
Paying the Piper
How should we pay a team to develop software?
[The ideas in this section are based on "Optional Scope Contracts", by Beck and Cleal.]
Some teams do a fixed-price quote: "Tell me what you want, and I'll tell you what it costs."
Here's how this looks if we assume a base cost to the developers, plus a steady spending rate:
http://xp123.com/xplor/xp0009b/index.shtml
6 of 7
2008-04-14 20:58
The developers are out some money from the start, and it's downhill from there. It's a zero-sum
game: every penny spent cuts the profit. The customer's goal is to get as much as possible, while
the supplier's goal is to do as little as possible. This is a hard conflict to overcome.
A second method is called "time and materials". Every company I've worked at has used this
model for its internal development: a chargeback per hour spent, plus costs for third-party
software, etc. The picture looks like this:
We've assumed here that every dollar spent has a proportionate amount of profit.
Inside a company, there are clear pressure points to apply to get the team to finish the job at a
reasonable cost. For a third party, the incentives to finish are indirect.
This contract makes the deal: "Tell me what you want, and I'll provide it - and you pay my
expenses until I get there." Where is the incentive to hurry?
There's an old story about a rich man who died, leaving two sons who both loved horses. The
man promised to leave his entire fortune to whichever son's horse got somewhere the slowest.
The sons got on their horses, poked along, in no interest to hurry. (Suppose you had volunteered
to feed them until the race was over...) This continued, until one realized, "We could ride each
other's horse, and turn it into a race for the fastest."
The time & materials contract has the same problem: there's a lot of incentive to dally. We'd like
to turn that into an incentive to hurry.
One way to do this is to break the job into chunks. The contract becomes: "Tell me what you
want for the first chunk, and I'll provide it if you pay my expenses. If you're happy with the result,
sign a new contract for the next chunk. Continue until you have what you want." If we put a cap
on the cost or time to deliver, and structure it so the supplier wants to deliver all the chunks, we're
better off.
Now, the incentive is to finish in reasonable time and with reasonable quality, to claim the whole
http://xp123.com/xplor/xp0009b/index.shtml
7 of 7
fee.
XP's key insight is to realize, "It doesn't matter if the scope changes over time - the team just
keeps working." Furthermore, by using small releases and tests to ensure quality, each version
delivered is useful and valuable.
Conclusion
We've talked about XP from several economic perspectives:
value and cost - the importance of the breakeven point
cost of money - the impact of net present value
XP's practices - how they potentially deliver better value at lower cost
option to quit - how small releases "lock in" value
payment models - how you might pay for XP software
Resources
"Optional Scope Contracts", by Beck and Cleal.
The Mythical Man-Month, Fred Brooks.
Extreme Programming Explained: Embrace Change, Kent Beck, 1999.
[September 26, 2000.]
Copyright 1994-2006, William C. Wake - William.Wake@acm.org
2008-04-14 20:58