The previous chapter modeled 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, & with greater likelihood
Spending money less, later, & 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 & 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, & discovered options pricing. Down the rabbit hole. I had recently invented TDD & I was looking 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.