11–18 of 18 posts
Any system's future state is not entirely predictable. We determine actions and their impact on current entropy while taking decisions.
But to the point of the article entropy only exists when external factors are introduced. Like new talent or tech paradigms changing the landscape of a startup.
better swap lives with money here
> irreproducibility could cost lives or even money better swap lives with money here
> irreproducibility could cost lives or even money better swap lives with money here
> irreproducibility could cost lives or even money better swap lives with money here
Earlier quoted context omitted.
Okay, so... in the coin flipping case, because entropy is already low, I follow the argument that generally attempts to add complexity are likely to make things worse. There's not much room to make things better to begin with. Not sure that it follow that the same conclusion applies in the cases of other engineering processes you listed, like "configuring a Linux base image for a specific server role" or "setting up…
"configuring a Linux base image for a specific server role" or "setting up a complex cloud environment from scratch" ^^^^^^^ I don't know if you have experience working this kind of thing but these processes have a single desired outcome and multiple undesired outcomes. They can break in many different ways and they do break more often than desired. One simple case related to setting up a Linux instance is when you w…
And in the case where you're re-following the same process but with newer dependencies, there are going to be multiple 'desirable' states you should end up in in the event that the latest dependencies available aren't compatible.
I just don't follow how this insight is meant to make it possible to evaluate how to get out of this mess?
Earlier quoted context omitted.
"configuring a Linux base image for a specific server role" or "setting up a complex cloud environment from scratch" ^^^^^^^ I don't know if you have experience working this kind of thing but these processes have a single desired outcome and multiple undesired outcomes. They can break in many different ways and they do break more often than desired. One simple case related to setting up a Linux instance is when you w…
"configuring a Linux base image for a specific server role" doesn't have a single desired outcome. There are a million ways to accomplish it. No two sysadmins would produce the same result. And in the case where you're re-following the same process but with newer dependencies, there are going to be multiple 'desirable' states you should end up in in the event that the latest dependencies available aren't compatible.…
This is not right. There are a million ways to implement the process. Once the process is implemented there is a single desired outcome which is the correct configuration, and every other outcome is undesired - you can have a procedure to test the servers, confirming if the configuration is correct.
The "million ways to accomplish" define a million different processes with different entropy levels. The ones with lower entropy levels lead you to the desired outcome more often.
"And in the case where you're re-following the same process but with newer dependencies, "
If it brings newer dependencies when you re-follow it is not a good process. That is one of the points to have in mind.
"I just don't follow how this insight is meant to make it possible to evaluate how to get out of this mess?"
Entropy is a way to count the failure modes of a process. For a given business requirement chose the simplest possible that respects it. I gave two examples in the article.