Tuesday, February 20, 2007

Why We’re not Ready for Real Options

More thoughts from my trip to Central Europe…

I attended a really instructive session at OOP 2007 presented by Hakan Erdogmus of National Research Council Canada on Principles of Software Process and Project Decisions. In this paper, Erdogmus proposes that we adopt the use of Real Option Analysis to inform and frame decisions in software engineering and agile project management. This isn’t the first time real options has come up for discussion. Chris Matts has been a proponent and real options were an active topic of hallway discussions at Agile 2006. It’s even come up from time to time in the Agile Management Yahoo! group.

Real option analysis is a mechanism for making decisions that would help us get beyond blunt management principles such as YAGNI (You aren’t going to need it). YAGNI pre-supposes that options are never worth buying. YAGNI is a reaction to the assumption in traditional software engineering advice that an option is always worth buying - for example options to build quality early in the lifecycle that involves extra cost on analysis, design and review, based on an assumed cost of change curve that shows exponential growth is cost of change late in the lifecycle, or options to build in reusability to a design that involves extra design, coding and testing effort. Kent Beck proposed a different cost of change curve that shows that buying an option based on quality early in the lifecycle is not a good bargain because the cost of fixing the problem later is actually much lower than the traditional curve suggests. In reality, we cannot generalize about cost of change - both curves are wrong. As I pointed out in my book, the cost of change depends on the position of the constraint (or bottleneck) in the software engineering value chain, and in the variability inherent in the domain and around the methods and skill level of the practitioners in that value chain. Real options provides a solution to this problem. Real options promise to offer a framework that will work for each specific situation rather than encouraging the use of a blunt instrument such as YAGNI that is blind to the true cost of change in a specific project.

So real option based decision making is desirable. However, I believe that we aren’t ready for it as an industry or profession. Here are my reasons why…

Real options require us to calculate two different numbers with some degree of confidence. The first is cost. We need to be able to calculate the cost of “buying” an option. So we need to be able to accurately apportion the effort involved in say investing in higher quality early in the lifecycle or in designing a class to be reusable as opposed to foregoing reusability and minimizing the design of the class. This effort estimate then needs to be turned in to a cost estimate. This cost amount becomes the cost of “buying” the option. Next, we need to be able to predict the variation in or probability that we would take up an option or that circumstances would develop such that we would wish to “exercise” the option, i.e. avoid time fixing bugs late in the lifecycle, or reuse a potentially reusable class or framework on a future project or iteration. Once we have both of these pieces of information we can make an informed option theory decision to either buy or pass on an option based on whether the cost of the option is less than the risk adjusted potential loss from not buying the option and suffering the consequences later.

The reality is that the as an industry and profession, we are years away from having the maturity to correctly measure and assess these data and hence I can only conclude that the day-to-day use of real option based decision making is still a long way off in software engineering. Where I feel we can salvage something from this is the paradigm of option based decision making. We need to encourage software engineers to think through decisions with like “are we going to need it or not and if so what would we spend now to balance that risk?” Getting software engineers to think about early lifecycle decisions as “options” will be a step forward to delivering better project decisions that are tuned to the specific situations and organizations rather than decisions based on generalized assumptions about the cost of change or the likelihood of reuse, even if those decisions are not based in reliably informed objective data. Technorati tag: Agile, David+Anderson, Real+Option+Analysis, YAGNI, Kent+Beck, Chris+Matts, Hakan+Erdogmus, OOP+2007