3 ms·

Kent Beck compares unwritten code with a financial option to buy something at a given price. But that's just an analogy, and it can be taken too far. If you ha

Kent Beck compares unwritten code with a financial option to buy something at a given price. But that's just an analogy, and it can be taken too far. If you haven't written any code, do you have infinite options? You haven't spent any time yet, but still, that doesn't seem quite right. It might be used to justify staying in the planning stage and putting off writing code indefinitely, to avoid committing to anything. Why might the analogy work anyway? Maybe the cost is reading the code? Code that hasn't been written doesn't need to be read. And if you're using a coding agent, it doesn't clutter up the context with irrelevant detail. Also, code that hasn't been written yet doesn't need testing. Tests you haven't written yet don't take any time to run. These are good reasons to try to keep a project as small as possible. By putting off features, you delay codebase growth as long as you can. This suggests that you can avoid a lot of costs by running someone else's code. If you can use a standard API then you don't need to understand the implementation in detail or run its tests. But there are risks to adding dependencies.

skydhash 4mo ago
> Kent Beck compares unwritten code with a financial option to buy something at a given price. From Kent's "Tidy, First?" Software creates value in two ways: What it does today The possibility of new things we can make it do tomorrow Unwritten code has no value. The code that is being written today, if it will be creating value, leans towards helping with with a request/issue today or helping making/solving things easier tomorrow. Then there's the various way of not creating value or favoring one of the two aboves. Either by taking on tech debt with hackish solutions or wasting time with YAGNI stuff. > If you haven't written any code, do you have infinite options? So it's not about unwritten code, it's about the code that you're going to write and it's purpose. And the correct tradeoffs between resolving the ticket/todo and not shooting your future self's foot. Writing code is commitment. And while the value for today is visible (either it's useful or it's not), the value for tomorrow is guesswork. But there's always some cost to be paid for later, so you guess in order to keep the cost minimal by anticipating what will be required.
- skybrian 4mo ago
  What corresponds to owning an option?
  - skydhash 4mo ago
    Again from "Tidy First?" 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.
    - skybrian 4mo ago
      This "scaffolding" sounds like some kind of code that you've written that you don't need yet? What's an example? Also, in the current article, it sounds like he's using "option" as a metaphor for something different? > Building early spends that option. You exercise it before expiry and throw away the time value.
      - skydhash 4mo ago

skydhash 4mo ago

> Kent Beck compares unwritten code with a financial option to buy something at a given price. From Kent's "Tidy, First?" Software creates value in two ways: What it does today The possibility of new things we can make it do tomorrow Unwritten code has no value. The code that is being written today, if it will be creating value, leans towards helping with with a request/issue today or helping making/solving things easier tomorrow. Then there's the various way of not creating value or favoring one of the two aboves. Either by taking on tech debt with hackish solutions or wasting time with YAGNI stuff. > If you haven't written any code, do you have infinite options? So it's not about unwritten code, it's about the code that you're going to write and it's purpose. And the correct tradeoffs between resolving the ticket/todo and not shooting your future self's foot. Writing code is commitment. And while the value for today is visible (either it's useful or it's not), the value for tomorrow is guesswork. But there's always some cost to be paid for later, so you guess in order to keep the cost minimal by anticipating what will be required.

skybrian 4mo ago
What corresponds to owning an option?
- skydhash 4mo ago
  Again from "Tidy First?" 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.
  - skybrian 4mo ago
    This "scaffolding" sounds like some kind of code that you've written that you don't need yet? What's an example? Also, in the current article, it sounds like he's using "option" as a metaphor for something different? > Building early spends that option. You exercise it before expiry and throw away the time value.
    - skydhash 4mo ago