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

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.