If that's the analogy, then I don't think it captures the core difficulty of software, which is unknown unknowns. That is, you write something that depends on an external system working a certain way, you follow its spec and depend on it working that way, and then it just ... doesn't, and you have to find exactly where it deviates, possibly making up some complicated kludge.
To capture that, there would have to be e.g. some hidden logic about which direction the output comes out that you have to deal with and work around until you understand it.
There's not a lot of unknown unknowns in factorio, but one thing which it really captures about software development is your own decisions coming back to bite you, or emergent complexity from notionally simple rules. As your factory grows you'll find yourself wishing you'd built things differently because suddenly something needs to expand beyond what you expected or some part of it is right in the way of a train network. Train networks are really tricky to make work effectively, it's very easy to have deadlocks appearing if you make a mistake, and you might not notice until you suddenly don't have any power because the trail with the coal is stuck waiting at a fouled up junction or something like that. There's a lot of opportunity to debug problems as they appear even in something you designed entirely yourself (and in a multiplayer game it's even more so because you might be detangling someone else's build).
A lot of the process of learning the game is basically learning patterns to reduce this. At the higher level of megabase design it's basically about designing a modular system so you can scale things out as efficiently as possible (and there's lots of possible variations of this).
IANAProgrammer, to some extent I create my own GIGO issues which are like small instances of poorly defined behaviour. Sometimes you'll realise your whole world has ground to a halt and it's a conveyor backed up because one item arrived at an inserter and blocked it.
I play a bit of DSP but have at least 3 different mitigations which are akin to input sanitising. However, if you just stick a filtered inserter by a conveyor to grab errant materials then it can comeback and bite you ... though I've found either I can route them back to the proper channel or I can get away with the technical debt by throwing enough storage at them and leaving it until the thing needs refactoring.
You can have too much realism! I like that every green-circuit board works, rather than getting failures of systems that use that item with some random errors (that increase of your closer to the sun, say). I think that would be too frustrating.
I think this could potentially be the Biters - the enemies in the game that will periodically attack your base. You can guess that they will attack your base, but you are never sure quite when and it's always a concern in the back of your head.
I think this part is captured by Satisfactory "Tier" system. As you progress in the game, you unlock Tiers which allow you to build new materials and structures. The issue often is that you optimize the hell out of your factories to build something that is needed at you current Tier, and when you unlock the next one, you suddenly have to refactor everything to build the new items, that require different ratio of materials and inputs.
If that's the analogy, then I don't think it captures the core difficulty of software, which is unknown unknowns. That is, you write something that depends on an external system working a certain way, you follow its spec and depend on it working that way, and then it just ... doesn't, and you have to find exactly where it deviates, possibly making up some complicated kludge.
To capture that, there would have to be e.g. some hidden logic about which direction the output comes out that you have to deal with and work around until you understand it.