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:
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.
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 3×5 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.
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 | Cost | Value |
|---|---|---|
| Whiz-bang word processor | $1M | $2M |
| Development environment | $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 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:
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 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.]