Wow, I’m really looking forward to reading this. It was really exciting seeing the last book take form and this one looks to be just as interesting, if not more. 😊
It's really good to see your thinking on approaching the whole thing and very good to see what's coming up, I'm looking forward to seeing the chapters coming out and being able to really get stuck into the process.
Also, I can't help but wonder how you're gonna keep the alliteration going for the third book, which also looks like it'll be an interesting read.
I know it's a little nit, but I have to pick it. Why is "Global to local state" the only technique that goes only in one direction if you "consider all refactorings reversible"?
I know it's a bad practice (in general practice), but if (in theory) you want to "give me the greatest number of paths through the design space", I can imagine someone invoking a punch line to an old joke "You can't get there from here". Are there no paths where local->global->local round-trips be helpful?
I'll include it for completeness. Thanks for catching that. I've had cases where something is passed absolutely everywhere as a parameter & turning it into global state is an improvement on the way to further improvement.
Hmmm.... Speaking of "improvement on the way to future improvement", before today's modern refactoring tools, I often "improved" the signature of a function by adding a comment at the end of the line, then adding every global variable. It "looks" like a bigger signature without (yet) "acting" like one. I called this "declaring implicit arguments", and it was often an "improvement on the way to a future improvement" of adding them as explicit arguments.
Having read your reply, I'm not sure if moving shared arguments to globals is better, or if the reverse transform is better. I guess it's always "It depends". It's great that it goes BOTH ways so that it can be undone if the experiment doesn't work.
I like adding the implicit arguments in a comment as a tidying.
Generally, reducing the scope and/or lifetime of state is good as it leads to a narrower scope for potential coupling, so that's the default direction. If some state, like the current database transaction, is used absolutely everywhere, then passing it explicitly adds no value, so the inverse direction does happen sometimes.
I'm so excited you are writing this book! I've been noodling on some of these ideas as well, but haven't had too many other folks to talk about it with. Really looking forward to reading more, and rooting for you!
If you're interested in power law distributions, are you aware of "On Being the Right Size". Here's just one of many links to the text. I (fondly) remember reading it in high school in an ancient looking boxed set of 3 (or 4) books with collected mathematical works.
Also called the square-cube law. It constrains growth of an organism (and as I later realized, an organization). Summary:
As an organism's height increases by factor of N, its surface area increases by factor of N^^2, and it's volume increases by N^^3.
Inputs and outputs (i.e. food and waste) are proportional to surface area by which they can pass
Energy requirement is proportional to volume.
If a human height is doubled, it's mass is 8x, but bone strength is only 4x and it can't support itself.
Grasshoppers get all the oxygen they need through their skin because no cell is too far away. We had to develop lungs (and digestive) to increase our surface area for inputs/outputs.
I once imagined my business as a single-celled organism/organization, and wondered what it would be like to scale to a mouse. I realized that would involve creating new organs. Animals do it in response to square-cube law. And I realized why so many "bureaucratic" processes exist. Blood is an analog to many bureaucratic communication systems, getting nutrients and oxygen to every cell (i.e. employee) and to eliminating their waste or distributing their information (i.e. hormones, glucose).
A mouse has more organs/systems than I wanted to manage, so I'm currently content to scale to a worm or a lichen.
The outline looks great! Very much looking forward to seeing the chapters as they come out.
Wow, I’m really looking forward to reading this. It was really exciting seeing the last book take form and this one looks to be just as interesting, if not more. 😊
I get to talk about the *real* geeky stuff. I'm so excited.
It's really good to see your thinking on approaching the whole thing and very good to see what's coming up, I'm looking forward to seeing the chapters coming out and being able to really get stuck into the process.
Also, I can't help but wonder how you're gonna keep the alliteration going for the third book, which also looks like it'll be an interesting read.
I wonder too. Sometimes you just have to let these things emerge. And then sometimes they don't emerge.
I know it's a little nit, but I have to pick it. Why is "Global to local state" the only technique that goes only in one direction if you "consider all refactorings reversible"?
I know it's a bad practice (in general practice), but if (in theory) you want to "give me the greatest number of paths through the design space", I can imagine someone invoking a punch line to an old joke "You can't get there from here". Are there no paths where local->global->local round-trips be helpful?
I'll include it for completeness. Thanks for catching that. I've had cases where something is passed absolutely everywhere as a parameter & turning it into global state is an improvement on the way to further improvement.
Hmmm.... Speaking of "improvement on the way to future improvement", before today's modern refactoring tools, I often "improved" the signature of a function by adding a comment at the end of the line, then adding every global variable. It "looks" like a bigger signature without (yet) "acting" like one. I called this "declaring implicit arguments", and it was often an "improvement on the way to a future improvement" of adding them as explicit arguments.
Having read your reply, I'm not sure if moving shared arguments to globals is better, or if the reverse transform is better. I guess it's always "It depends". It's great that it goes BOTH ways so that it can be undone if the experiment doesn't work.
I like adding the implicit arguments in a comment as a tidying.
Generally, reducing the scope and/or lifetime of state is good as it leads to a narrower scope for potential coupling, so that's the default direction. If some state, like the current database transaction, is used absolutely everywhere, then passing it explicitly adds no value, so the inverse direction does happen sometimes.
I'm so excited you are writing this book! I've been noodling on some of these ideas as well, but haven't had too many other folks to talk about it with. Really looking forward to reading more, and rooting for you!
Thank you for the support!
If you're interested in power law distributions, are you aware of "On Being the Right Size". Here's just one of many links to the text. I (fondly) remember reading it in high school in an ancient looking boxed set of 3 (or 4) books with collected mathematical works.
Also called the square-cube law. It constrains growth of an organism (and as I later realized, an organization). Summary:
As an organism's height increases by factor of N, its surface area increases by factor of N^^2, and it's volume increases by N^^3.
Inputs and outputs (i.e. food and waste) are proportional to surface area by which they can pass
Energy requirement is proportional to volume.
If a human height is doubled, it's mass is 8x, but bone strength is only 4x and it can't support itself.
Grasshoppers get all the oxygen they need through their skin because no cell is too far away. We had to develop lungs (and digestive) to increase our surface area for inputs/outputs.
I love this essay and can't say enough about it.
So I will....
I once imagined my business as a single-celled organism/organization, and wondered what it would be like to scale to a mouse. I realized that would involve creating new organs. Animals do it in response to square-cube law. And I realized why so many "bureaucratic" processes exist. Blood is an analog to many bureaucratic communication systems, getting nutrients and oxygen to every cell (i.e. employee) and to eliminating their waste or distributing their information (i.e. hormones, glucose).
A mouse has more organs/systems than I wanted to manage, so I'm currently content to scale to a worm or a lichen.