Chapter 26. Options

The previous chapter modeled the economic value of a software system as the sum of the discounted future cash flows. We create value when we change those flows:

• Earning money more, sooner, and with greater likelihood

• Spending money less, later, and with less likelihood

Working inside this model as a software designer already isn’t easy. We live in a Goldilocks world: not too much design or too soon, not too little design or too late. But wait, there’s more. (If it was easy, everybody would already be doing it and there’d be no excuse for this book.) There’s another, sometimes conflicting, source of value: optionality.

Decades back I worked with trading software on Wall Street. I did the background reading, as I like to do, and discovered options pricing. Down the rabbit hole I went. I had recently invented test-driven development (TDD), and I was looking for practice topics. Options pricing seemed like a great example: complicated algorithm with known answers.

I implemented the extant options pricing formulas test first (discovering the need for an epsilon when comparing floating-point numbers in the process). Along the way I developed an intuition for options that started to leak out into my general thinking about software design.

I can’t implement all those algorithms for you, but I can report the lessons I learned (I encourage you to try the exercise if you really want to “get it”):

• “What behavior can I implement next?” has value all on its own, ...