4 ms·
(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 explai
by 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 agoI 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 agoI 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).
- prometheus76 2y agoI disagree with the part where you say "complex systems can be reduced to smaller and simpler ones where making a decision doesn't have to mean unleashing a cosmic horror." 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. https://www.youtube.com/watch?v=kojH8a7BW04 https://www.youtube.com/watch?v=kojH8a7BW04