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:
- 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
- Any software is programmed in a highter level language
- 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
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 all other Weenies just cann't undestand each other... they all have different strategies to deal with complextiy and when one of the thinks that a particular place is the ideal place to hide complexity it turns out that is precisely the place that another one think is not the place where complexity should be dealt with....
No comments:
Post a Comment