Economics Of Xp

First, a dollar tomorrow is not as good as a dollar today. If I have a dollar today, I get to earn interest on it. If I have a dollar tomorrow, I haven't earned any interest on it.

Let's take a simple example, because I don't want to do lots of math (see FunctionObject for the REALLY easy way to do this). Let's say I will spend $1 today to build a piece of software and in one year I will earn $2 from it. I just made $1, right? Not quite. I spent $1, but (at 5%), I only earned $1.91. So I made $.91. Not bad, eh?

Not so fast. I know I spent that $1, because I spent it today. How sure am I that I made those $2? 80%? 50%? Software development is tricky, and the market has a nasty way of changing out from under you. Let's say we're really good, and the market is kind, and our probability of taking in $2 is 80%. We can only count on 80% of our $1.91, or $1.52. So, if we are comparing investments, our profit viewed from today is $.52.

Now, these are obviously cooked numbers, but the form of the analysis is correct. When analyzing whether a project makes monetary sense, you have to take into account when the money flows, and how likely it is to flow.

What does this mean when thinking about a DisciplineOfSoftware? It means that you want to push investment as far into the future as possible, and you want to pull revenue in as close as possible. It also means that you want to do everything in your power to increase the probability of a project surviving (does anyone have supportable numbers for how many object projects actually go into production?)

Methodological orthodoxy goes exactly counter to this advice. It says to invest more now and wait longer for returns. Work hard to achieve reuse. Don't rush into coding. And its long feedback cycles compound risk (there are notable exceptions to this- somebody or other's RiskManagement comes to mind).

I think you missed one important point in your calculations. In most environments, you will spend the $15M over the next three years. Your choice is not whether to spend the money, but what you spend the money on. You can have your developers sit on overhead and have nothing in 3 years, or work on your theoretical project and have $45M, or work on something else and have a different amount. And all of the return amounts are speculative any way.

I find this particularly evident in games. For example, we've been playing a lot of Starcraft (http://www.blizzard.com) in our office, and beginners spend too much time building up big, expensive buildings to let them build big, nifty units. They quickly get crushed by the hordes of small, cheap units that the computer sends after them. This comes up in a lot of other contexts as well, some of which are undoubtedly better for explaining to software managers than computer games.

Business, particularly American business, is often accused of "short-termism". Perhaps this is an example of harmful "long-termism"

-- AlanKnight

This sounds like an argument for IncrementalDevelopment. That is, by releasing software in chunks that add value to the user one can defer some investment until late in engineering cycle.

It is certainly an argument for IncrementalDevelopment, and it is more. The argument also says that developers should be very cautious about putting in capabilities now that they believe will be useful later. This is the argument that supports our infamous rule YouArentGonnaNeedIt. --RonJeffries

IncrementalDevelopment and YouArentGonnaNeedIt create value as a result of two economic effects: time value of money (which encourages earning early and spending late) and option value (which applies to investment decisions under uncertainty). Option value accounts for the bulk of the total value generated if there is significant uncertainty. See the related discussions: FinancialEffectsOfIterations and EconomicsOfYagni. -- HakanErdogmus

see also the CostOfDesignCarry and http://xprogramming.com/xpmag/cost_of_change.htm

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006