Home > Articles > Software Development & Management > Agile

Extreme Programming and the Economics of Software Development

  • Print
  • + Share This
Kent Beck shows you how to maximize the economic value of a software project by paying attention to cash flows, interest rates, and project mortality, from his book Extreme Programming Explained.
This chapter is from the book
We need to make our software development economically more valuable by spending money more slowly, earning revenue more quickly, and increasing the probable productive lifespan of our project. But most of all we need to increase the options for business decisions.1

By adding up the cash flows in and out of the project, we can simply analyze what makes a software project valuable. By taking into account the effect of interest rates, we can calculate the net present value of the cash flows. We can further refine our analysis by multiplying the discounted cash flows by the probability that the project will survive to pay or earn those cash flows.

With these three factors—

  • Cash flows in and out
  • Interest rates
  • Project mortality

we can create a strategy for maximizing the economic value of the project. We can do this by

  • Spending less, which is difficult because everyone starts off with pretty much the same tools and skills.

  • Earning more, which is only possible with a superior marketing and sales organization, not topics we will cover in this book (thank goodness).

  • Spending later and earning sooner, so we pay less interest on the money we spend and we earn more interest on the money we receive.

  • Increasing the probability that the project will stay alive, so we are more likely to get the big payoff late in the project.


There is another way of looking at the economics of a software project—as a series of options. Software project management can be looked at as having four kinds of options:

  • Option to abandon—you can get something out of the project even if you cancel it. The more value you can take from the project without actually delivering it in its originally envisioned form, the better.

  • Option to switch—you can change the direction of a project. A project management strategy is more valuable if halfway through a project the customers can change the requirements. The more often and the more violently the requirements can change, the better.

  • Option to defer—you can wait until the situation has sorted itself out before investing. A project management strategy is more valuable if you can wait to spend money without completely losing the opportunity to invest. The longer the deferral and the more money that can be deferred, the better.

  • Option to grow—if a market looks to be taking off, you can grow quickly to take advantage of it. A project management strategy is more valuable if it can gracefully scale up to greater and greater production given greater investment. The faster and longer the project can grow, the better.

Calculating the worth of options is two parts art, five parts mathematics, and one part good old-fashioned Kentucky windage.

There are five factors involved:

  • The amount of investment required to get the option

  • The price at which you can purchase the prize if you exercise the option

  • The current value of the prize

  • The amount of time in which you can exercise the options

  • The uncertainty in the eventual value of the prize

Of these, the worth of options is generally dominated by the last factor, the uncertainty. From this we can make a concrete prediction. Suppose we create a project management strategy that maximizes the value of the project analyzed as options by providing

  • Accurate and frequent feedback about progress

  • Many opportunities to dramatically change the requirements

  • A smaller initial investment

  • The opportunity to go faster

The greater the uncertainty, the more valuable the strategy will become. This is true whether the uncertainty comes from technical risk, a changing business environment, or rapidly evolving requirements. (This provides a theoretical answer to the question, "When should I use XP?" Use XP when requirements are vague or changing.)


Suppose you're programming merrily along and you see that you could add a feature that would cost you $10. You figure the return on this feature (its net present value) is somewhere around $15. So the net present value of adding this feature is $5.

Suppose you knew in your heart that it wasn't clear at all how much this new feature would be worth—it was just your guess, not something you really knew was worth $15 to the customer. In fact, you figure that its value to the customer could vary as much as 100% from your estimate. Suppose further (see Chapter 5, Cost of Change, page 21) that it would still cost you about $10 to add that feature one year from now.

What would be the value of the strategy of just waiting, of not implementing the feature now? Well, at the usual interest rates of about 5%, the options theory calculator cranks out a value of $7.87.

The option of waiting is worth more than the value (NPV = $5) of investing now to add the feature. Why? With that much uncertainy, the feature certainly might be much more valuable to the customer, in which case you're no worse off waiting than you would have been by implementing it now. Or it could be worth zilch—in which case you've saved the trouble of a worthless exercise.

In the jargon of trading, options "eliminate downside risk."

  • + Share This
  • 🔖 Save To Your Account