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.
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 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.
you can think of "Optionality" (which is the Y axis) as the flexibility of the code to handle more future changes; the more features you add, the less flexibility you end up with.
enhancing the optionality between features (refactoring) would increase the flexibility of your code
Definitely struck a chord with me; thank you for this article.
I struggled a bit to understand "optionality". My brain needed to map it to something I could process.
When starting from 0, I typically use ready frameworks, services, or tools, open-source or from paid products. What keeps the options high at that moment? Those things I use, people have tidied and built for others to like the options so much, as to part with their dollar. I weave out of these great looking tidy product and services.
When I build my own pieces for myself, I become my own client. Since I am my own client, I make compromises in the "tidiness". In fact, what does 'tidy' mean? I may feel ashamed to show it to someone, where that relates to my reputation and pride, if others see how untidy this thing has come out.
Do I understand correctly that making something tidy, and increasing the options means that I can weave with it easier and faster, and actually, I can even show it to others and not loose my reputation anymore, and possibly let someone else make money out of it for their business because I have "tidied"?
If I move to this framework of thought, then to understand the cycle of creating something new and tidying after that would mean that we regularly make our work more like a library we can proudly offer to someone else to include and build upon. This may mean good documentation, cleaner APIs, clear modularity, a bit of generality and pluggability in various other frameworks so new innovation can easily compose, etc etc.
Then I become a good client of my past self's work, and optionality comes back to a high level.
How do I understand the higher-than-original point optionality as we progress with tidiness cycles? After a certain level of tidiness, a synergy unlocks, similar to the software market one, where tools and services can combine (unless deliberately locked down by a vendor) to produce more value.
One more thing – one may ask, why not always build tidy the first place? Anyone who has launched new products knows that most of these are bets, so quick and dirty does the work of bet-checking with the market. BUT, once you have found a relatively good bet, then tidying needs to kick in; otherwise, the pile of quick and dirty bogs down the speed of innovation in a compounding non-linear manner. I've written a bit more about this using the metaphor of "maturity" and "fake" technical debt. Manipulating the optionality with an investment basically corresponds to a maturity beyond the market bet proof that will allow for fast innovation after that again. I'll probably add a section on the implication of compounding debt that reduces optionality bogging down innovation speed. This is my initial article on the maturity and decay observations - https://medium.com/se4humans/fewer-reasons-to-hate-technical-debt-973e292b6143
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.
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 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.
It seems to be a nice article/post, but I don't got the "options" meaning
my understanding is the following:
you can think of "Optionality" (which is the Y axis) as the flexibility of the code to handle more future changes; the more features you add, the less flexibility you end up with.
enhancing the optionality between features (refactoring) would increase the flexibility of your code
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?
I don't get why the features are closer and closer. I thought the axis was # features and not time.
What am I missing?
Definitely struck a chord with me; thank you for this article.
I struggled a bit to understand "optionality". My brain needed to map it to something I could process.
When starting from 0, I typically use ready frameworks, services, or tools, open-source or from paid products. What keeps the options high at that moment? Those things I use, people have tidied and built for others to like the options so much, as to part with their dollar. I weave out of these great looking tidy product and services.
When I build my own pieces for myself, I become my own client. Since I am my own client, I make compromises in the "tidiness". In fact, what does 'tidy' mean? I may feel ashamed to show it to someone, where that relates to my reputation and pride, if others see how untidy this thing has come out.
Do I understand correctly that making something tidy, and increasing the options means that I can weave with it easier and faster, and actually, I can even show it to others and not loose my reputation anymore, and possibly let someone else make money out of it for their business because I have "tidied"?
If I move to this framework of thought, then to understand the cycle of creating something new and tidying after that would mean that we regularly make our work more like a library we can proudly offer to someone else to include and build upon. This may mean good documentation, cleaner APIs, clear modularity, a bit of generality and pluggability in various other frameworks so new innovation can easily compose, etc etc.
Then I become a good client of my past self's work, and optionality comes back to a high level.
How do I understand the higher-than-original point optionality as we progress with tidiness cycles? After a certain level of tidiness, a synergy unlocks, similar to the software market one, where tools and services can combine (unless deliberately locked down by a vendor) to produce more value.
Does this interpretation make sense?
One more thing – one may ask, why not always build tidy the first place? Anyone who has launched new products knows that most of these are bets, so quick and dirty does the work of bet-checking with the market. BUT, once you have found a relatively good bet, then tidying needs to kick in; otherwise, the pile of quick and dirty bogs down the speed of innovation in a compounding non-linear manner. I've written a bit more about this using the metaphor of "maturity" and "fake" technical debt. Manipulating the optionality with an investment basically corresponds to a maturity beyond the market bet proof that will allow for fast innovation after that again. I'll probably add a section on the implication of compounding debt that reduces optionality bogging down innovation speed. This is my initial article on the maturity and decay observations - https://medium.com/se4humans/fewer-reasons-to-hate-technical-debt-973e292b6143