I don't remember exactly when it happened, but it was many years ago that I reached an intuitive understanding of the law of conservation of energy. One way to state this law is: "Energy can neither be created nor destroyed." My perception of the world was forever changed the moment that I first understood this idea. This was a similar moment to when I first intuitively understood the theory of evolution. These are ideas, that when you really understand them, reach out their tendrils and snake their way into every aspect of your perception. Nothing can escape their implications.
So I found it fascinating to read this posting to comp.lang.forth (which was linked to from the programming reddit), in which Elizabeth Rather discussed a certain axiom supposedly formulated by Chuck Moore.
She referred to it as "conservation of complexity," and it goes like this:
"Any given problem has a certain intrinsic level of complexity. In the solution of the problem, this complexity will be conserved: if you dive in with too little advance thought, your solution may become very complex by the time it's done. On the other hand, if you invest more in thought, design, and preparation, you may be able to achieve a very simple solution (the complexity hasn't gone away, it's become embodied in the sophistication of the design)."
After reading that description, a light bulb lit up in my head as I realized that this may be another one of those deep ideas. Conservation of complexity may be a special case of conservation of energy. This is very intriguing and seems to me to intuitively make sense. Looking back on software I've written, I have indeed seen this in action. I even once told a co-worker at my last job, when we were discussing the design of a program I was writing for him, that, "I want all the complexity on me, not on the users." I convinced him to change the requirements of the program so I could shove more of the complexity "behind the curtain," as it were, and not burden the users with it.
So really what Chuck Moore has (supposedly) said is just a more elegant formulation of what I have known to be true of software all along: you can move complexity around, but you can't destroy it.