5 ms·

Have you ever seen Sorcerer's Apprentice from Fantasia? I haven't seen the movie, and the original poem it's based on is in French, so I only have seen it in th

Have you ever seen Sorcerer's Apprentice from Fantasia? I haven't seen the movie, and the original poem it's based on is in French, so I only have seen it in the Disney form. That being said, it's the perfect analogy for what is a deliberate decision by the sorcerer's apprentice to enchant a broom and get it to start bringing water in from the well outside into the cistern in the room. The process starts, and everything is going well, but it's taking too long. So he finds a way to make two brooms. Then ten...etc. Things quickly get out of hand and he can't find how to stop the brooms, and the whole room gets filled with water (chaos). At the last minute, the actual sorcerer appears and sets everything aright, and chastises the apprentice for his foolhardy curiosity in meddling with things he doesn't understand. 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.

msephton 2y ago
(author) I disagree, as you might expect. :) 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.
- Sakos 2y ago
  I think one aspect is that often we make decisions without fully understanding the consequences. 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).
  - msephton 2y ago
    I absolutely agree with you on that. I had just edited my answer above to include a fi all paragraph basically saying the same thing. It doesn't need to be black or white, one or the other, it can be both or anything in between. The fact that one system might be too complex to contain doesn't rule out a much smaller system that can sit quite happily in the mind of a single person. 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.
    - Sakos 2y ago
      > The fact that one system might be too complex to contain doesn't rule out a much smaller system that can sit quite happily in the mind of a single person. 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).

msephton 2y ago

(author) I disagree, as you might expect. :) 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.

Sakos 2y ago
I think one aspect is that often we make decisions without fully understanding the consequences. 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).
- msephton 2y ago
  I absolutely agree with you on that. I had just edited my answer above to include a fi all paragraph basically saying the same thing. It doesn't need to be black or white, one or the other, it can be both or anything in between. The fact that one system might be too complex to contain doesn't rule out a much smaller system that can sit quite happily in the mind of a single person. 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.
  - Sakos 2y ago
    > The fact that one system might be too complex to contain doesn't rule out a much smaller system that can sit quite happily in the mind of a single person. 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).