People, like code, do not operate indeoendently of their environment.
An isolated town of shockingly healthy individuals [1] showed that our health depends not only on factors intrinsic to us (genetics) or controlled by us (diet and exercise). Health is hugely influenced by community. We can’t be understood in isolation.
When a bug turns up in test or production, people love to ask “what did we change? That last code change must be the cause!” No. Lots of things changed. Different users from last week are typing in different input. The contents of the database are not identical. Perhaps the hardware has changed, or some downstream system is reacting differently. When a problem occurs, we should look at the problem, dig down until we know what happened, and then we shall find the cause. Sometimes it is the code change, and by finding it by understanding the problem, we will know how to fix it. (By something other than knee-jerk “back it out!”)
Programs and people are both defined not only by internal state, but also by the world around them.
——–
[1] Outliers, by Malcolm Glad well, preface.
[2] This makes a case for functional programming. Functions that are referentially transparent, or “data in, data out”, do not access external state. Output depends only on input. Results are the same every time, for the same input. This is testable. Write as much of your code as possible in this style, and the fragile parts will be isolated. Purely referential code is useless in the real world, but it is easier to test.