JBoss Archive Browsing

Today I learned that jboss-archive-browsing.jar is in fact an "slice" of the much bigger jboss-common.jar
and that, if I want to download the code from that project, I have to go here.
(It is important to remember the code in jboss-archive-browsing has an ugly bug that makes it impossible to
use Hibernate if you entities are inside a .jar)

Complication & Complexity: Not the same thing

Today I learned that Complication & Complexity are not the same thing:

• Complexity: A problem is complex when you do not know how to solve it, the solution might be simple, or complicated.
• Complicated: A problem is complicated when you know the exact algorithm that solves it, but the algorithm has lots steps and/or you need to follow lot of well known rules.

Self learning: Knowledge is power

Here I am reading about Decision Making, Software Engineering and Network Security. That is what I love to do... reading... learning... but lately I have not felt inspired... I felt like... like there was nothing worth learning anymore... I guess I was just overwhelmed with work and the stress of life, because I am regaining my will to learn more... always learn more...

I think that maybe what re-started my desire for knowledge was a conversation I had today with my girlfriend... we were talking about how was it possible that most people didn't do problem analysis before trying to solve problems with their work processes... I think it is because they know anything about the real meaning of Six Sigma and how to measure quality in a process, we think it is logical to start analyzing the current situation because we learned that from our university courses on software engineering but... why should anyone else know about it? Most people are pressured at work to "just do something" to solve problem without stopping to determine first what are the root causes for the problem they need to solve, and they end up treating the symptoms instead of the disease, and transform a problem that could have been solved with a single action in to a chronic problem that needs to be handled again, and again and again.

The sad part is that a lot of time the solution for the problem has been known by some people for quite a long time, but the person that is assigned to solve the problem ASAP in a particular place doesn't know that the problem he is dealing with was solved a long time a go, and he/she end up spending an excessive amount of time and energy to discover a partial solution to a problem that would have been easy to solve if he/she had the right information.

My favorite example of this are source code versioning systems... the first one (Source Code Control System (SCCS)) was invented in 1972, but today, 36 years later I still arrive at software departments or even software enterprises that do not use any software for version control... how is that possible if really good versioning systems like SubVersion are opensource and free? and have excellent integration with Windows (TortoiseSVN), I believe it is because of "lack of knowledge", people just doesn't know that there are free and easy software to deal versioning and they end up designing complex proceedings to manually handle the versioning of files... they do it that way because they plain do not know there are better ways...

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)

Code depreciation

Depreciation is a term used in accounting, economics and finance with reference to the fact that assets with finite lives lose value over time (from Wikipedia), I this case, I'd like to discuss code depreciation and its relationship with optimization and mantainability by proposing the following rule:

If code is written for performance (compromising maintainability), the value of such performance optimization (and maintenance degradation) will depreciate, because the likehood of having either faster hardware or different developer maintaining the code increases as time passes.

On the other hand, maintaintable code, increases its value for similar reasons:

If code is written for maintainability (postponing performance enhancements), the value of that maintainability (and performace degradation) will increase its value, because the likehood of having either faster hardware or different developer maintaining the code increases as time passes.

I added this definitions to C2... I wonder how (or if they) will evolve.