Law of Conservation of Complexity

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....

It was programmed with...

Lately I have been seen people at work saying "I built that system using Php" or "We should build all our applications with Java" or "All our applications should be built with Ajax" or "We should (or should not) use Java/J2EE", but in the majority of the cases it turns out that the final product is something that is not built with a single technology but a combination of several ones... and the problems with that show up when we start to integrate applications:

• Integrating this applications will be easy they both use WebServices (Yes, but one of them uses JSON, another SOAP, another REST and another used Hessian)
• Lets combine this two web applications in to a single one (Yes, but one of them is built using Spring+Hibernate and the other was built with JDBC+Home Made Wannabe Framework)
• The architecture of this applications is very similar they are both OLTP applications, integrating their code bases will be easy (or exchanging developers between them will be easy) and it turns out one of them is built using Stored Procedures in PL/SQL, another uses TopLink and the last one uses IBatis.
• This two applications are AJAX bases it will be easy to integrate them (or exchanging developers between them will be easy) .... ups, they use to completely different and perhaps even incompatible AJAX frameworks

So... are we really saying something that somehow resembles the truth when we say "I built that application with XXXX"? I think not... but then... why do we keep saying stuff like "That was built in Java" if there are 1000 different ways to build it with Java.... 1000 ways to build with AJAX, 1000 ways to build it with PHP, 1000 ways to build it in .NET ... and millions of ways to build it, if we start combining this "base" technologies.

Ruby is younger therefore better than Java?

I wrote this as a response to From Java to Ruby: Programmer's view, but I couldn't post it because of a bug in that site, so I decided to post it in my own blog:

Isn't this a simplified view of the advantages of Ruby over Java? For example the lack of choice in Ruby means that if the "one Ruby way" to do stuff is not good for you project... you will have to go to other technologies (Java for example). And that can happen pretty often:

• Hibernate has many more options for integration with legacy databases than Ruby's Active Record... almost all databases now have JDBC drivers (you can not say the same about Ruby database support).
• Spring offers integrated transaction handling that makes it possible to switch from JDBC transactions to JTA transactions without changing a single line of Java code (you just need to modify around 5 lines in an XML file) what is the equivalent for that in Ruby?
• Calling stored procedures is not that easy with Ruby... what is the equivalent of HQL (JPAQL) for Ruby... can you honestly say that it can handle all the special cases HQL can... and with the same efficiency?
• With java I can build a web application GWT style, JSF style or plain JSP style... and each style has advantages and disadvantages... do I have all that power with Rails? (Of course, those frameworks can be re-built in Ruby, but the question is, do I have them now?)

I think you are right when you say that it's healthy to start with a clean slate and rebuild based on a cleaner, simpler foundation, but before saying that the new foundation is actually better than the older one, you have to be sure that your new foundation is actually capable of handling all the special cases the old foundation was capable of handling... or remember that maybe if you remove all the abilities the old foundation has to handle special cases you might end up realizing that your new foundation is just a replica of the state that the old foundation had when it was younger. (And even then the older foundation has the advantage that you can use it as it was used in the past, but you can not use a new foundation as it will be used in the future)