If you’re a developer, you might be familiar with the concept of determinism:
a system in which the later states of the system follow from, or are determined by, the earlier ones1
It’s a concept that is used heavily in functional programming to provide consistency and reliability in programs. What it fundamentally means is that outputs are determined purely by inputs. As far as I can tell, the terms usage in programming is predated by it’s usage in philosophy, where it describes someone who believes that the world we live in is bound by that same rule. That outputs are controlled absolutely by their inputs. Even predominant scientific minds like Stephen Hawking subscribed to a variation of this belief, as he details in his book The Grand Design.
Now I feel it’s my duty to communicate clearly, I am a developer, not a physicist or in any way someone with the authority to speak about the intricacies of quantum physics2. This post isn’t intended to persuade you to subscribe to this belief, rather to consider it’s implications if it is true. Therefore most of this post will be written as if it were true.
The first implication regards free will. If our outputs are results of our inputs, it implies that our decisions are determined by what has happened to us in our life. From macro inputs such as where we are born, who we spend time with and what we read, to micro inputs such as the complex nerve interactions in our brain, these could be used to accurately predict everything we have ever done or ever will do. Despite this, we would still retain an illusion of free will, since we are currently unable to observe many of these inputs/outputs.
Let’s consider what this means for someone using software I wrote. If they opt to try using it in a way other than what I intended, that was the only possible outcome for them. Their confusion regarding the usage of my design is purely a result of the inputs they were given.
So what can we do armed with that knowledge? First off, I think it’s important to identify which of those inputs we developers can control, which in this case the most clear is the design itself. The system I have built is the most obvious input I can control that could have prevented their struggle. Which would lend itself to the belief that the user isn’t always right because they are paying us, rather because they weren’t equipped to arrive at any other conclusion.
Make no mistake, I’m not suggesting that developers should always cater to the whims of their users. There are plenty of cases where I don’t believe it makes sense to do so, such as in FOSS3. Nor am I suggesting that we shouldn’t have systems in place for when our users invariably do struggle. Instead, I’d like to suggest that the common practice of blaming our users for their mistakes isn’t a very productive line of reasoning, and that we’d be better off treating even the most ridiculous mistakes as if they are rational. Because to the user they are.
And maybe this can be more widely applied outside of software too. Maybe we can all collectively recognize that many of the foolish decisions we have seen individuals make are merely products of systems that are part of their lives. That blaming those individuals makes little difference4. And that fixing broken systems that serve as inputs to our society would have greater impact.
Of course that’s all based on the assumption that people are deterministic, which I would invite you to come to your own conclusions about.