The subject of technical futures is closely related to TechnicalDebt

A former colleague of mine (http://www.bath.ac.uk/~ensjbb/) introduced me to this idea when we were working on a CIM project that required the introduction of computer networking on the shop floor of an engineering factory (in 1990 this was quite exciting). We knew that it was TheRightThingToDo but the investment appraisal models used in engineering factories at the time required something more solid than gut feeling. Jerry developed an analogy with the financial futures markets. 

The idea is that you can pay a small amount of money now to buy the opportunity to do something later (usually at a specified price). If you choose not to do the thing later, then your money is lost. If you exercise your option, then getting the benefit for the previously specified price constitutes a return on your investment of the option price earlier on. (This concept should be fairly familiar to most of us in the industry, now that share options are a standard form of incentive.) 

If you want to invest in some technology (let's say for example a refactoring project, or a clean but more expensive first write), you can sometimes justify the expenditure by explaining that it will give you the potential to take on tasks or projects that would otherwise be impossible or more difficult/expensive. Potential is worth money. The financial markets understand this, investors in technology start-ups understand this, and software professionals ought to understand it too. -- DominicCronin

''Isn't this precisely the kind of situation that YouArentGonnaNeedIt mandates avoiding, or is it more subtle than that? The above text sounds to me like you're saying that it's possible for us to be able to do some work now which may give a return on that investment (i.e. save us more work) in future. In practice, in the technical arena the former action influences the latter, whether or not we choose to actually exercise the option - unlike its financial analogue. For example, consider writing some code today and planning a TechnicalFuture with it: we will either save ourselves some work in future by writing the code now or we can throw it away in future. Both outcomes must occur at some (agreed) mutual point in time. However, in the software world, it's quite possible that the TechnicalFuture will be invalidated before expiry for various reasons: someone may need to change your code such that it no longer is possible to remove it from the codebase. You create more maintenance overhead potentially beyond the lifetime of the "option", despite the good intention.''

''Isn't this just a question of RiskManagement, though?''

''Yes - to some extent this is a different perspective than YouArentGonnaNeedIt. YouArentGonnaNeedIt represents the extreme case where the value of the future is taken to be zero. I like the suggestion that it's risk management. After all, isn't that what the guys in the financial markets are doing when they buy and sell futures. YouArentGonnaNeedIt then translates as "I'm not prepared to risk any investment without a known payback". Some projects really '''are''' characterized by being able to make a cheap investment now that would be more expensive if you wait until you need it. Perhaps YouArentGonnaNeedIt has a fuzzy value, which for ExtremeProgramming projects is always taken to be 1.''

While YouArentGonnaNeedIt is usually true, in some projects, one already has planned features in next or after-next iteration, and it is obvious that a specific change will pay dividends.  What developers shouldn't do is just go ahead and do this work without checking with the product owner.  With a close relationship, the customer can be informed of this future you're selling, and if they want these upcoming features, may accept a shift in priorities.  It must be kept in mind that if you're doing anything near two-to-six-week iterations, there's already plenty of ability to shift directions.  It seems wise to only use TechnicalFutures when it's absolutely obvious to everyone that the upcoming features will use these proposed alterations, and only if it's in the near-term.  Modern refactoring tools and solid testing reduce the cost of refactoring later, so the relative value of TechnicalFutures needs to be kept in context. --ChristianEdwardGruber

----
This is perhaps best applied when the cost of adding the "hooks" for the future feature is relatively low.  Or even extremely low.

For instance, CopyAndPasteProgramming is usually less work than OnceAndOnlyOnce, but OnceAndOnlyOnce isn't '''much''' more expensive, and saves an awful lot of work if you do have to change things in the future.

'' Yes - The analogy with financial futures holds up best if you maintain the notion that the extra short-term cost is small compared to the investment you're buying the right to make in the future.'' 
----
See also: TechnicalDebt