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:

Any software is programmed in a higher level language (instead of assembler)
File based persistence is changed for SQL based persistence.
An object relational mapper is used to translate objects in to tuples.
A remoting framework is used instead of plain TCP/UDP API
An object oriented framework framework is used to build a web app instead of a plain C cgi.
An operating system provides a GUI instead of just a command line
Object vs. Relational where both data and process must be communicated.

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:

measuring complexity: unless we can measure complexity like we can measure mass and energy, we'll never move ConservationOfComplexity past hypothesis. It's even difficult to prove that two systems have the same complexity. The closest we come in current science is 'entropy', which really isn't the same (to my understanding, complexity is based upon dependencies, which indicates order and coupling; comparatively, entropy is all about disorder and decoupling). (ComplexityMetrics)
essential vs. non-essential complexity: any software can be made more complex by programming it in InterCal or by being intentionally convoluted. This suggests that it is possible to create complexity. If it is possible to create complexity by being intentionally convoluted, that suggests that it is possible to create complexity by being unintentionally convoluted. Chances are, we aren't working at anywhere near optimum in the systems in use today. That suggests that it is probably possible to reduce (or 'destroy') complexity. (EssentialComplexity)
complexity regarding dynamic requirements: In business, software requirements are never correct and never complete - that's a fact born of experience. If complexity introduced by changing software requirements can be mitigated or reduced by choosing one approach over another, that suggests that complexity can be destroyed. The current hypothesis for ConservationOfComplexity does not explore this possibility.
complexity introduced by negative constraints: Negative constraints include things like soft and hard real-time, security requirements, safety requirements, and even code-certification requirements; they introduce extra hoops that the software (as an emergent system) must pass. The idea of ConservationOfComplexity has not explored these conditions. Likely problems include DiscontinuitySpikes where it seems complexity is a great deal higher... (e.g. attempting to certify safety over assembler vs. over a high-level language: the increased complexity of the certification process for assembler may well swamp entirely the relative cost of building a compiler and proof-system for the higher-level language.).

(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:

Using POJOS instead of J2EE
Using REST instead of SOAP
Using religion instead of science to explain the universe (or perhaps the other way around?)

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? ( http://en.wikipedia.org/wiki/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?

CategoryComplexity