Yeah, software gets bigger as more requirements are thrown at it, no matter how it's done. Eventually you just end up with a these balls of crap. Frankly, I th

Yeah, software gets bigger as more requirements are thrown at it, no matter how it's done. Eventually you just end up with a these balls of crap. Frankly, I think this pattern describes most programming constructs as well. As what's a good approach for managing largeness (or complexity)? Dividing it into smaller simpler understandable chunks, that can be changed in isolation, which is what containers attempt to do, as what many programming constructs attempt to do. But you're right, it'll just grow more, and things will likely just get divided again into more chunks. I don't see a way out of this process. In fact, I feel this describes a general law, as it describes everything large in general. Take companies for example. Large companies are less innovative, because they're more complex and hard to change, just like large software. Additionally, large companies tend to containerize things into divisions, departments, teams, and so on, in attempt to manage complexity. Bigness is the anti-thesis to change/innovation...