Conservation Of Complexity

This is a hypothesis that software complexity cannot be created or destroyed, it can only be shifted (or translated) from one place (or form) to another. Some proposed examples:

Supposing that these shifts are designed to accomplish the same tasks, ConservationOfComplexity suggests that each of the above maintain the complexity of the software. If you program in a high-level language, you shift complexity into the parser and compiler. If you utilize SQL-based persistence instead of file-based persistence, you're shifting a complexity burden unto the DBMS (and similar for object-relational mappers, remoting frameworks, etc.). If you use a command-line instead of a GUI, you shift some complexity from the computer to the human-user, and vice versa.

Potential stumbling blocks for the hypothesis of ConservationOfComplexity:

(Snipped from above in refactoring; below three too specific or not clearly applicable. Rest seems to be opinion and speculation (heading towards fancy after the mention of 'Conservation of energy') rather than clarification or explanation. It seems premature, given that ConservationOfComplexity has yet to be established.)

In short, the law of conservation of software complexity states that complexity can not be created or destroyed, it can only be changed from one place (or form) to another, such as when:

In all this cases, it seems as if complexity were reduced, but, in fact, it was only moved to a place where it can not be seen, that, in my opinion it the reason that motivated the creation of encapsulation in object oriented languages, to make it easy to move complexity around, and hide it from some developers to make their work easier (but, in the end, the complexity is still there, and sooner or later you will need the help of the creators of the framework/database/gui... or if is opensource and you have the time and energy, you might have the courage to go and fight directly with that hidden complexity... but the final fact is that complexity is never destroyed, it is just moved around.

Maybe that is why ObjectWeenies? and RelationaWeenies? and FunctionalWeenies?, and AllOtherWeenies? just cann't understand each other... they all have different strategies to deal with complexity and when one of them thinks that a particular place is the ideal place to hide complexity it turns out that is precisely the place that another one thinks is not the place where complexity should be dealt with... and a HolyWar begins.

Is this a software law like the law of Conservation of energy? ( )

Or could it even go beyond that? Like an UniversalLaw?? would it go against entropy? or perhaps a PhilosophicalLaw?? or a LifeLaw?? for example, some people say that criminals want to get "easy money" to have an "easy life" but... is the life of a criminal really easier? criminals have to handle less complexity in their lives? or they only chose to handle the complexities of life in a way that seems to be easier (robbing banks), but it that in fact is way more complicated (having to hide from the police for a long time, worrying about getting killed of betrayed, spending the money in small amounts to avoid being noticed, etc, etc)?

Is the conservation of complexity linked to the ItDepends idea?

See Also: WaterbedTheory, EssentialComplexity, ComplexityMetrics


View edit of May 12, 2008 or FindPage with title or text search