Financial options have these parameters:
The *underlying* thing that we can buy
The *price* of the underlying, including the volatility of that price
The *premium* of the option, or the price we pay today
The *duration* of the option, or how long we have to decide whether to purchase the underlying
So, there's some behavior of the software that we may want which correspond to the underlying of the option. That behavior will have a value for to the business later which is it's price (can be 0 or negative). We can spend time and money to create its scaffold (the premium). The duration is how much time we can spend with the scaffold especially if it raise the cost of other behaviors.
So you own an option when you create the scaffold (paying the premium). So you're already writing code, but there's nothing valuable to the business yet. Owning an option can be good as in you're not paying the full price yet. But you've paid something and it can impact your budget for adding fully realized features (which is the only thing that is truly valuable to the company).
If you can keep a lot of potential behaviors (your options) in your portfolio (your codebase) open while keeping the cost of creating them minimal, then your portfolio become more resilient. As today's is tomorrow's past, your value as a developer is what behavior you can extract from your portfolio to create the valuable thing for the business (which is the only thing your employee and/or customers care about). Having an option that have kept the price cheap is what matters.
In the financial world, you need to pay to own an option. The "option" he is talking about, you paid it in terms of time to construct the scaffolding.
You need a feature F, you can build feature F directly (no options, just creating what is valuable today). One example is using an external dependency directly in your business logic.
You can also build enough abstraction so that feature F is decoupled enough from the rest of the project that the latter only have a logical view of it (which hardly changes). That can be done cheaply, making it easier to easily modify the code according to the business logic. You just go a little further than the previous version, but without really committing to the anticipated changes. Like hiding the dependency behind an interface of your choosing.
You can also over engineer the solution anticipating changes that are not likely to happens (buying options at very high cost). One example is writing an ORM layer because you may need to switch from sqlite to SQLServer. Or writing an agnostic UI library because you may need to support everything from HTML to raw OpenGL and ncurses. The issue there is that there's no requirements (from stakeholders) or business values in supporting those use cases.
> > Building early spends that option. You exercise it before expiry and throw away the time value.
In the last case, you've written code, aka consuming time and money, for a scenario that is uncertain. And even if they do realize, your code would likely be worthless as the assumptions behind it does not match the real requirements. The threshold between the last and the second case is that in the latter, you're not committing to the future design. You're laying some groundwork that leave future work, when needed, easier to accomplish.
