Thank you for your thoughtful and valuable insights! One question struck me: on your last chart, how can we end up with more options than we had on the green field?
I mean, I would have expected that tidying allows us to recover parts of our "lost options", to get a bit upward along the y-axis, a bit closer towards the level we had in the beginning. But getting above that, how's that possible?
Great question! One micro example: Say I have a long function. I extract a helper to prepare for a change. I make that change. I go to write the next feature. I write a function. Discover to my surprise that the recently-extracted helper is exactly what I need to write the new function. I had more options for that second function because tidied first.
I had a similar thought to Felix and Julius after reading the post. I have experienced what Kent describes, where a new abstraction becomes a vantage point from which I can see farther. But that's never been the long-term trend on my projects.
It's frustrating and surprising, because it seems like every new function we write should give us *more* options, or at least, shouldn't limit our options. But that's not how it feels in practice, most of the time. I wonder if there is something other than optionality at play, or if the theory of optionality could be generalized to account for this phenomenon.
I agree with Felix. It might be possible in theory. I have never seen it happen in one of my projects. I tidy and refactor but getting above that level of initial possibilities does not happen - at least not for me
If I write a payroll system it's suddenly much easier to write a time tracking system to go with it (if the payroll system is sufficiently option-y). If I fix a bunch of genuinely painful lint violations then adding the next feature is going to go more smoothly. We may not think of what we are doing as creating options, but we are or rather can be.
I had the same initial reaction as Felix and Julius, but I get it now - byproducts of A become products B and C. It might not be so clean and linear as the graph depicts but at least it's possible to creat more opinionality than Zero. At zero you're thinking "this is the thing I will build" but as more options open up you can build "that thing" and maybe "the other thing" if it makes sense to do so at some point in time.
Thank you Kent, it gets much clearer now. I think we were thinking of two different kinds of options, and I'm trying to put my finger on it. I was thinking of a, let's say, theoretical possible set of design decisions, assuming the current design as fixed. More or less. Which means, it gets more and more specific over time, so the number of options shrinks.
You, on the other hand, talk about the practically feasible enhancements I can implement in my software. That's of course not only much more valuable per se, but also leads to the nice outcome that the number of options can easily keep growing over time, with improving tooling, structure, frameworks, libraries, integrations etc.
Thank you for your thoughtful and valuable insights! One question struck me: on your last chart, how can we end up with more options than we had on the green field?
I mean, I would have expected that tidying allows us to recover parts of our "lost options", to get a bit upward along the y-axis, a bit closer towards the level we had in the beginning. But getting above that, how's that possible?
Great question! One micro example: Say I have a long function. I extract a helper to prepare for a change. I make that change. I go to write the next feature. I write a function. Discover to my surprise that the recently-extracted helper is exactly what I need to write the new function. I had more options for that second function because tidied first.
I had a similar thought to Felix and Julius after reading the post. I have experienced what Kent describes, where a new abstraction becomes a vantage point from which I can see farther. But that's never been the long-term trend on my projects.
It's frustrating and surprising, because it seems like every new function we write should give us *more* options, or at least, shouldn't limit our options. But that's not how it feels in practice, most of the time. I wonder if there is something other than optionality at play, or if the theory of optionality could be generalized to account for this phenomenon.
I agree with Felix. It might be possible in theory. I have never seen it happen in one of my projects. I tidy and refactor but getting above that level of initial possibilities does not happen - at least not for me
If I write a payroll system it's suddenly much easier to write a time tracking system to go with it (if the payroll system is sufficiently option-y). If I fix a bunch of genuinely painful lint violations then adding the next feature is going to go more smoothly. We may not think of what we are doing as creating options, but we are or rather can be.
I had the same initial reaction as Felix and Julius, but I get it now - byproducts of A become products B and C. It might not be so clean and linear as the graph depicts but at least it's possible to creat more opinionality than Zero. At zero you're thinking "this is the thing I will build" but as more options open up you can build "that thing" and maybe "the other thing" if it makes sense to do so at some point in time.
Thanks, that helped. My confusion: optionality == code quality. Code quality produces options.
Thank you Kent, it gets much clearer now. I think we were thinking of two different kinds of options, and I'm trying to put my finger on it. I was thinking of a, let's say, theoretical possible set of design decisions, assuming the current design as fixed. More or less. Which means, it gets more and more specific over time, so the number of options shrinks.
You, on the other hand, talk about the practically feasible enhancements I can implement in my software. That's of course not only much more valuable per se, but also leads to the nice outcome that the number of options can easily keep growing over time, with improving tooling, structure, frameworks, libraries, integrations etc.
I feel like that there is a limiting factor on both options and features: purpose.
Could it be said that the act of refactoring/tidying features is an expanding factor on options to a greater extent than on purpose?
And that that is why there is inevitable convergence?
I also suppose that the sign of a **__good__** developer is that they can increase that expanding factor more than others?