Searching for value in the tomato garden

by John Favaro

August 2013

In the IT profession we spend a lot of time talking about evaluating our “Return on Investment,” often forgetting that we are really talking about an entire hierarchy of activities:

• Business strategy—Selecting markets in which to participate and formulating strategies for competing in those markets;
• Valuation—Analyzing the economic value of projects executed in the pursuit of that business strategy;
• Cost-benefit analysis—Translating measured or estimated data into monetary terms (for example, labor costs), forming the basis for valuation;
• Metrics—Measuring the parameters (such as programmer time) that form the basis for cost and benefit analysis.

Reading the literature, it’s immediately evident that the software engineering community has done an enormous amount of work in the last two areas, but has nearly neglected the first two. Why? Because we’re software engineers: we feel comfortable with gathering and interpreting metrics, which are naturally “close to the code”; but few of us have been exposed to the most elemental building blocks of economic valuation, concepts such as present value and the cost of capital. Even fewer have thought very much about their relationship to terms that we use informally all the time such as Return on Investment and Time to Payback. But valuation forms the basis for the disciplined thinking that is necessary for any serious assessment of economic value.

An example: in the IT community, we are not only interested in the economic value of our products, but also the value of our software engineering processes. Consider the new generation of methodologies we have come to call “agile” (several of the Technology Transfer seminars deal with these new agile approaches); the most well known of these is called Extreme Programming. It has always been a difficult job to assess the economic value of development processes, partly because most interesting scenarios involve abstractions like quality, portability, or extensibility. The scenarios involving agile methods seem to be the most problematic of all, because in the end most of them involve the objective of flexibility. And what could be more abstract, more elusive to evaluate, than flexibility?

In fact, it has been just over thirty years since an advance was made that provided some real hope of progress in the economic evaluation of flexibility. This was the publication in 1973 of the formula for pricing financial options, by the economists Black, Merton, and Scholes (the Nobel Prize was awarded to them in 1997for this achievement). In 1977, another great economist named Stewart Myers recognized that the theory of option pricing in the financial world might also be applicable to projects in the real world. Since options imply alternatives, and alternatives imply flexibility, “real options” were soon being investigated for the economic valuation of projects involving flexibility. By the 1990s it was recognized that the malleable nature of software made it a strong candidate for this approach.

The iterative style of development in agile approaches makes it possible to change priorities, introduce new features, delay implementation, etc. You could say that an agile development team is continuously creating and managing “options” as it adapts to changing conditions. This “options-driven” perspective on agile processes was introduced as early as the first book on Extreme Programming.

This is where the metaphor of the tomato garden comes into play, originally developed by finance professor Timothy Luehrman to illustrate the idea of active management of a portfolio of strategic options. The tomato garden metaphor is also surprisingly effective at illustrating a flexible, iterative software development process under uncertain conditions. Luehrman introduces the metaphor in this way: “Walk into the garden on a given day in August, and you will find that some tomatoes are ripe and perfect. Any gardener would know to pick and eat those immediately. Other tomatoes are rotten; no gardener would ever bother to pick them. These cases at the extremes (now and never) are easy decisions for the gardener to make. In between are tomatoes with varying prospects.”

This is analogous to the situation in iterative development processes that implement software in terms of well-delimited packages of functionality such as the “use cases” of the Rational Unified Process or the “stories” of Extreme Programming. On a given day in an agile project you will find stories with varying prospects. Some are ready to implement, while others have been recognized as impossible, or perhaps too costly to implement.

Continuing with the metaphor: “Some tomatoes are edible and could be picked now but would benefit from more time on the vine.” This refers to what is known in the terminology of real options as the option to defer, which has demonstrable economic value in many kinds of situations from oil exploration to building construction. Agile processes also create this economic value by making it possible to defer implementation of stories to later iterations (for example, in order to clarify requirements before taking a final decision).

Continuing with the metaphor: “A purely passive gardener … picks the ripe tomatoes and goes home. Active gardeners [not only] watch the garden but, based on what they see, they also cultivate it: watering, fertilizing, weeding.” In many traditional software development environments, what’s finished is finished – you only return to what you have done if absolutely necessary (motivated partly by a fear of “breaking it”). But in an agile environment, the system is being cultivated all the time: finished code is refactored, tests routinely “break” the system, and integration is continuous. The system is never in repose – but as a result, the options available at any time are maximized.

Luehrman: “Of course, the weather is always a question, and not all the tomatoes will make it. Still, we’d expect the active gardener to enjoy a higher yield in most years than the passive gardener.” We all know from bitter experience that despite our best efforts, some external condition can always doom our projects – whether it is a radical change in the requirements, or a top-level management decision, or a sudden funding cut. But the discipline of real options, together with other modern financial concepts, is finally beginning to provide concrete support for the intuitive argument that active, agile management of a project, whether it be this summer’s tomato garden or this winter’s web services system, will increase its economic value.

Will the emerging discipline of real options ultimately provide that silver bullet for understanding the economic value of our software engineering best practices? Certainly not – it’s clear by now that there is no silver bullet, only hard work and disciplined thinking. But the more we learn about fundamental principles of finance and its modern advances, the more disciplined our thinking will become and the more our hard work will yield worthwhile results.