I think this was the original paper:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7745181/
Sample size was 43k people split in treatment and control group. Adding it here for context.
158 karma · joined June 10, 2023
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7745181/
Sample size was 43k people split in treatment and control group. Adding it here for context.
Here is a simple tool that can help exploring sample sizes:
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.
^^^^^^^
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 want to have the "latest and greatest" python libraries without even checking if the stable versions of an LTS distribution would actually suit you. You end up with a huge list of things from pip, a list that sometimes breaks (even with fixed versions) and where security updates do not guarantee retro-compatibility. One day it works, next day it doesn't.
Your process has more entropy than necessary and is less reproducible than desired.
If instead of a server instance you have a docker image that is rebuilt in a CICD pipeline, you have the same problem but blocking an entire team that is expecting CICD to work all the time.
This is just a single point of failure of many others that can coexist: a "corporate" transparent proxy with cache, an unreliable DNS server, a security appliance that interferes with downloads, etc.
As for rebuilding cloud environments you really have to go through it to see how entropy scales with complexity. I could write a couple of pages about it.. and about how people are actually building cloud snowflakes. Here is a short take:
You can reduce the probability of every outcome you can initially think of, plus the ones you find out along the way. As time passes you will converge to a situation that is strongly dominated by the desired outcomes.
The central point of the article is complexity enlarges the undesired outcome space, even if introduced the the intention of reducing it. Perhaps this is less clear than desired.
* heads, no issues
* tails, no issues
The articles says this:
"The way to lower that maximum is to bring N to a number as close as possible to one. In addition to reducing the number of possible outcomes, we can further reduce entropy in any given process by reducing the probability of every undesired outcome,[...]"
which applies to a reproducible process. In the case of coin flipping, the desired reproducibility refers to having no issues, so N should be as close as possible to 2".
(the macrostate vs microstate distinction could be introduced but it would complicate the argument)
This is an important point. Don't try to do what Facebook/Google/etc do because you are not Facebook or Google and you don't have a team to support the same complexity levels nor the budget to invest until that point of maturity. Trying to be like the big ones is a classic trap.
This is a dangerous statement. Some tech stacks are way more complex (and therefore more expensive) than others. You need to choose wisely what you use, because whatever you put in production will stay with you for at least 5 years (thumb rule...) and rewriting is a pain.
https://logical.li/blog/team-capacity/
* avoid hype trains: it is a trap
* avoid complexity unless there is business based justification: it is another trap
* understand that every thing you build needs maintenance
* understand that the integrations you build for something you don't build also need maintenance
* software has many layers: choose where to be disruptive and where to be conservative
* avoid superficial cultural assumptions like "smart good junior people that hug trees will do wonders": you need a couple of pragmatic engineers to impose common sense in the operations
* avoid bogus metrics like "I deployed to production 20 times last month" and embrace sound metrics like "we delivered the features on time with few or none bugs found in production"
* foster an engineering culture: ensure people understand context, tradeofs and relevant metrics
snap refresh --hold
was made available my team went through the pains of snap workarounds [1]
The LXD team was very proactive in the support side but the truth is that Snap is a pain and without --hold it would be possible for production servers to break out of a sudden due to uncontrolled updates (who did every think that this was a good idea?).
LXD itself is a very good project because it uniformizes the use of containers and VMs with a friendly CLI - the syntax is more intuitive than the one from Docker, by the way. We recently managed to combine LXD and Puppet to manage containers and VMs in a declarative way. I am a big fan of the LXD project.
Somebody else commented here that the latest Debian makes LXD available in the normal distribution packages - that is something worth checking.
[1] - https://discuss.linuxcontainers.org/t/repeatable-lxd-install...
Found a lot of inspiration from blogs discovered via HN.
The very fact you were able to write this post in such an articulate way already puts you ahead of 90% of the population. Have you seen how people write? I've been managing teams and projects in the last 18 years and I can promise you that written communication skills, along with patience to use them, are as important as coding skills, if not more important.
"Intelligence" per se is overrated. Work performance comes from a mix of intelligence, patience, communication skills and persistence. In real life, documentation and traceability (from well commented tickets) are as important as lines of code.
I hope you recover soon to full capacity. Just wanted to let you know that I'm not used to such fluent writing, neither from 17 year old people nor from the average colleague at software companies. You have that on your side.
Furthermore, please sue the idiots if you can.
Wish you a fast recovery!
Actually we are back to creating silos. More "modern" and more expensive silos.
I recently started a new blog with the idea of giving something back. This is my first submission. I will deep dive in other topics as time goes by.