In the first part of this series, we covered what optionality means.
To recap, having more options is more valuable than having less, and that value increases the more uncertain things become.
How does this relate to software?
Fundamentally, optionality is what determines the value of software.
This is counterintuitive for many folks, including myself. Isn't it the case that it's what software does that makes it valuable?
To see why functionality is only a small part of software's value, let's look at an example. Take two imaginary accounting apps; GoodBooks and Account Aunt.
Both are pretty basic; they allow us to generate invoices, track incoming and outgoing payments, and export your data in CSV format so you can load it into an Excel spreadsheet. But then, GoodBooks adds a new feature. Now you can generate projected financial forecasts to see how your revenue and outgoings look up to 12 months into the future. Wouldn't it be the case that this app has now become more valuable than Account Aunt?
To some extent, yes. If I were a customer evaluating both apps and with all other things being equal, I would rationally choose the app with the forecasting feature over the one that does not. In time, we would expect the more feature-complete app GoodBooks to start picking up more and more customers and eventually 'win' against its competitor. As such, on this one simple (but still important) dimension, the app with the forecasting feature is more valuable.
But very rarely, in life and business, are all things equal. Prices, marketing, branding, and a host of other factors all interact to mean that the app's functionality is only one small part of what could lead to its eventual success or failure.
In this tangled web of complexity, the one constant is uncertainty. What will our users actually pay for? What happens if a new start-up enters the market? What if some of our employees quit? Every entrepreneur knows the only thing for certain is that nothing is certain.
In the face of such uncertainty, the ability to change and adapt becomes critical. And as we concluded earlier, where there is greater uncertainty, the value of having options, of optionality, increases.
This is a profound, point, which didn't click fully for me until 10 years into my career writing code1. It answers the question posed in the first article in this series, about how given two identical apps, one could be worth ten times more than the other.
Let's go back to GoodBooks and Account Aunt, and imagine once more they are identical in every way apart from the forecasting feature. If the GoodBooks app (belying its name) is a horrible hack job, built in a rush by people who took no care to test, document, or structure it well, it will make it much harder to change.
Without tests that automatically check that everything works as expected whenever we alter the code, we risk inadvertently breaking the app. Without documentation, we may waste hours or even days trying to understand the context in which the code was written, like trying to solve a Sudoku puzzle when you've never done one before and cannot look up the rules. With a poor structure, we could easily end up in a Rube-Goldberg machine-like mess, where one small innocuous change in one part of the app triggers a huge cascading error somewhere else unexpectedly.
We cannot change GoodBooks quickly, safely, or easily. In contrast, with a test suite catching the (inevitable) errors that occur when making changes quickly and reliably before any user is affected, with documentation that gives the context in which decisions have been made, and with a structure that facilitates rather than obstructing changes, it becomes clear why Account Aunt would be worth so much more, even despite being feature-poorer.
This is the essential value of engineering, and why companies invest in it. This is why optionality is the first topic I wanted to cover in the Engineering Thinking series, as it underpins essentially the entirety of why thinking like an engineer is such a valuable mentality to adopt.
Given all this, it might be surprising to find that there are still valid reasons why an investor would take the harder-to-change GoodBooks software over the high optionality Account Aunt app, especially in the world of startups. We're missing an important variable in the equation, which we'll cover in the next article.
Time.
Here’s the next article in the series:
From Kent Beck’s Tidy First? p.70: “I thought I was getting paid for what I had done… I wasn’t. I was mostly getting paid for what I could do next”. Reading this was a real 🤯 moment for me as an engineer.