This behavior is by design
blog.gingerbeardman.com
blog.gingerbeardman.com
> The fundamental truth remains: behind every line of code, every pixel, and every feature, there are human decisions shaping our experiences.
This is true, but does not mean that those human decisions intended to shape our experiences actually ended up shaping them in the intended way, especially in aggregate.
The more correct statement is: "You might need to fret even if inscrutable things were shaped by human decisions, because outcomes frequently end up unrelated or totally contrary to the human intent behind those decisions even in total absence of malice or even mistakes."
I specifically mention bugs and glitches, unintended consequences, happy accidents (unintended things that become intended by virtue of them being kept rather than discarded), unequal weight given to decisions, and more. Of course I don't use your exact wording, but it's all there. I try to keep it neutral, rather positive vs negative outcomes, just "decisions".
I am a glass half full kind of guy so perhaps the text is a little more positive than neutral.
It has an automatic playlist feature where it automatically queues up next episodes based on some simple rules.
One of the rules is "alternate podcasts" to ensure that you rotate through podcasts rather than listening ot just one because it happens to be the oldest or similar.
I noticed that I was always listening to the same two podcasts despite having this feature enabled.
It turns out that whenever it downloaded a new episode it would regenerate the playlist and forget about where it was in the rotation. So when I finished and episode it would download the next one and reorder the queue, putting the other podcast next.
I filed that to the developer and they said "working as intended", when you change the set of downloaded podcasts the playlist is regenerated. And said they wouldn't fix it.
But this behaviour is clearly not what it should be, it defeats most of the point of the "alternate podcasts" flag (It only works correctly if you only ever have two eligible podcasts or disable auto-download)
We could use some of that humility with regard to interfering with complex systems. Most of the effects of perturbations of a complex or chaotic system are unpredictable, and great care should be exercised before making a change, and even with great care, most of the effects will be surprising and unpredictable.
So yes, on a superficial level, all decisions in software are deliberate, but the way those decisions interact, and the outcomes of those decisions are unpredictable and largely unknown when the decisions are made. Also, and you mentioned this in the article, many of the decisions are not made deliberately, after much reflection, but rather, on the fly and in the moment.
To hand-wave that all away by saying "but a human made it" seems pretty disingenuous, or at least extremely naive.
I'm an independent developer who makes video games, one of which - YOYOZO - was voted a GOTY in 2023. I can explain every single line of that source code and every parameter, variable and constant. I could also explain the physics system I created, my graphics rendering, replay system, scoring calculations, and so on. Nothing is in my code by chance and everything was written by me. I can appreciate the that some people find this difficult to believe, even more so if that type of from-scratch solo-development seems alien.
Mine is a bit of a special case because I code games from a blank file without using engines like Godot, Unreal, Unity, Game Maker. Could every game developer explain every part of the game they're making? Of course not. But if one person can claim it then we know it can be true.
I agree with you that some systems can be so complex that it would take a huge effort to understand or predict all possible outcomes, like breaking encryption. But that's not all systems. So I think it's not so black and white. It can possible and impossible, easy and difficult, obviously human and done by design or less obviously human with the intent shrouded in complexity. It doesn't have to be one or the other, it can be both.
The decision might be a conscious choice, but the consequences of that choice may be unintended if it's a complex enough system and there's insufficient knowledge of the system to recognize all the potential consequences.
And sometimes (often?) it's not possible to know all the possible states a particular system can end up in. This is the whole point of paradigms like functional programming and ideas like immutable state. It's the recognition that even if we put in the most utmost care, there might be more possible states than we're able to comprehend and account for.
It might be possible, with a lot of care, for a solo programmer to control the state explosion associated with developing an application, but once there's more than one developer, once there's a team and an existing codebase (or code bases) that's been around for 20-30 years, it's impossible without doing NASA levels of verification.
And all of that is before considering how our decisions affect what decisions we can make in the future or how it shapes those decisions (as well as affecting the decisions of others that we may never meet).
I'd also like to thank you for bringing up the consequences of choice. Maybe I'll add that as an extra section at some point, as I feel I have a lot to say about it.
Yes, definitely. Also that complex systems can be reduced to smaller and simpler ones where making a decision doesn't have to mean unleashing a cosmic horror.
> I'd also like to thank you for bringing up the consequences of choice. Maybe I'll add that as an extra section at some point, as I feel I have a lot to say about it.
Sounds great. I really enjoyed your post.
I've often been in these situations where a customer will ask why a certain thing works a certain way and I'll overhear the discussion between the developers who, as it turns out, only inherited that decision from somebody else, but the response is all the same: "This is the intended behaviour". Even though nobody currently at the company ever intended it to behave that way. We might placate the customer by mentioning we might take a look at it in the future, but it's the same as a user accepting the defaults. The current owner accepts the current behaviour and becomes complicit in the design decision, even implicitly becoming the reason why it persists until the next owner (and probably every owner after that).
That's the whole problem with reductionist thinking, which fails when analyzing a chaotic system or a complex system. The behavior of the whole is greater than the sum of the parts because of hidden interactions between the smaller parts of the system. There are too many variables to account for, and small variations in initial conditions rapidly became very divergent outcomes.
I get the sense that you may not have studied chaotic systems or complex systems in any level of detail. It might be a worthwhile effort to learn more about those systems, because they are essentially a refutation of reductionist thinking.
You may understand your codebase completely, but I assure you, if you released it to a large enough group of people, they could find errors and bugs in your code because they will try things that would never occur to you.
I am reminded of a video where a programmer spent three years training an ai model to beat an "impossible track" in trackmania, where he finds out that chaos built into the deterministic physics engine behind the game made his pursuit much more difficult.
> I get the sense that you may not have studied chaotic systems or complex systems in any level of detail. It might be a worthwhile effort to learn more about those systems, because they are essentially a refutation of reductionist thinking.
There's a world of difference between a chaotic system like the weather and something designed and implemented by humans like a set of interconnected micro-services. I couldn't possibly hope to comprehend all the factors and variants and invariants in a weather system, but I can understand (to a certain degree) how services interact, how data flows through a human-built system, how data is represented and processed inside of a service.
It's usually possible to improve parts of a system so you don't necessarily need to take the whole system's complexity into account in every decision you make. And I think we're all at least implicitly aware of it, or we wouldn't waste our time with worrying about abstraction, encapsulation, side-effects, coupling, or mutable state. We wouldn't have all these books about how to design software architecture or write clean, maintainable code.
> There are too many variables to account for, and small variations in initial conditions rapidly became very divergent outcomes.
If that were true, we might as well all pack up and give up. I can figure out what inputs might end up in a certain method and what outputs are possible for given inputs. And if I can't because of how the method is designed, then I can make changes that reduce the relevant state to the point where I can reason about them. There are countless variables in a system, sure, but the amount of variables at a particular point of a codebase that actually need to be accounted for are not necessarily countless. With the wrong architectural decisions, they can be countless, but that's why we avoid things like global mutable state. We are responsible for the complexity of a particular software system, which also means we have the ability to reduce or increase the complexity with the decisions we make.
> I am reminded of a video where a programmer spent three years training an ai model to beat an "impossible track" in trackmania, where he finds out that chaos built into the deterministic physics engine behind the game made his pursuit much more difficult.
Well, yeah, if that's the kind of system you're talking about, then sure. That's a complex system that can't be simplified or reduced, because you're literally trying to approximate real world physics. The purpose of that system is inexorably tied to its complexity. I don't envy programmers who have to deal with that form of system.
> You may understand your codebase completely, but I assure you, if you released it to a large enough group of people, they could find errors and bugs in your code because they will try things that would never occur to you.
I don't understand this argument. I might not be able to get rid of all bugs, but that wasn't a claim I ever made. We definitely can reduce the amount of bugs we have and the amount that we create with new code by making efforts to control the complexity affecting the code we write.
> because of hidden interactions between the smaller parts of the system
Going back one last time, yes, there are often hidden (or unknown) interactions between different parts of a system, but our only option isn't just to say, "well, I guess there's no way to deal with that, let's make that new feature and hope it works out".
An important part of maintaining/improving a software system is uncovering these interactions and making them an explicit, visible part of the system (or removing them if they're unintended and unwanted), as well as evaluating the possible risks and consequences of decisions being made and how/when/where to mitigate them as best we can to the best of our current knowledge.
Also an important part of designing these systems is reducing how different parts of a system are coupled to each other, isolating them from each other and localizing their effects as much as possible.
You might not be able to reach some Platonic ideal of a simple non-complex system with no unintended interactions, but it is clearly possible to move a complex software system in that direction and there are plenty of benefits for doing so.
Building quality software is hard because it’s the mistakes and oversights that get noticed.
It’s much easier for someone to claim it’s “by design” than to try and fix it.
The use of "This behavior is by design" as the title of my blog post was intentional, so that it could be interpreted as either positive or negative by the reader.
The reminder to consider the intent behind design choices is valuable. It helps us appreciate the complexities and nuances that go into creating software
The greatest danger is that humans will forget how to verify that we aren't an AI. If the AI is sentinent, and somehow attempts to prevent us from talking to each other, unless we are talking through it, then we get into trouble.
Since AI is nothing without social media, one could say that these models would be meme powered, leading humans (hopefully) to recognize the cliché and pastiche of the entity, and turn it off - probably by simply ceasing to talk to it, in as many ways as humanly possible.
The danger is that we won't recognize the need to do this, and the whole world turns into a massive computer. Not just every single human, but every single thing involved in human life...