Best XML Quote

XML is like violence. If it doesn't solve the problem, use more.

I'm not sure who came up with this quote. I stumbled upon it in Slashdot. And a quick google on it shows that it is being repeated over and over as an anonymous quote. Regardless of who first came up with it, it encapsulates a always-present malady of the IT world: the abuse and misapplication of technologies and principles.

You know there is something wrong when two applications are communicating via XML when both belong to the same owner, are written in the same language, run on the same network, are not exposed to third parties and yet communicate via XML. By third parties, we mean systems that at best are owned by different organizations within the same company, and at worst, are owned by different entities and are external to each entities' physical networks.

A typical example of this type of abuse is having a web application A having to go through another web application B to retrieve information from a database C, when A and B are written in the same language and A, B, and C being within the same network vicinity. Worse still when the intermediary application breaks down the database results into malformed XML documents.

Not only does this ignore the perennial impedance mismatch that is characteristic of all modern applications that communicate with databases. It also compounds the problem by using the wrong technology to communicate results in this manner: XML. It is not only cumbersome, but it is also inflexible in representing ever-changing data relationships in the database as well as CPU/memory inefficient.

You only use XML when two distinct applications that are external and separate to each other and need to communicate through discrete and well-defined interfaces. Nothing else really justifies plastering XML all over communication protocols.

Why Kolmogorov's pOjOx?

So the 1-mill question I get is why I named my blog this way. Well, in good modular fashion, the answer is composed by three not totally independent components, glued together by their amorphous interfaces with ad-hoc literary middle ware.

Some in the IT industry will rise their fist and yell "yeah" when they read my explanation. Others will simply not like it as it constitutes a slap in the face of their daily professional practice. If you are not allergic with overly and premeditated verbose rhetoric, read on.

Why p0j0x?

For starters, p0j0x, that's my quasi-hacking rendering of POJO (Plain Old Java Object) in l33t speek, a tribute to the old hax0r posters from the long-gone days of the Usenet. Perhaps it is a bit of nostalgia for the days when people were more concerned with demonstrating their technical excellence instead of using IT as a materialistic platform to chase, in rabid, morbid, virulent, almost psychotic and certainly obscene and plain dirty fashion, for 6-figure salaries, hard talk and the dream of retiring to a life of wasteful consumerism by the age of 40.

More than nothing else, the name p0j0x stands for my not-so-veiled disdain for the sacrifice of technical excellence combined with my admiration of simple technologies to get things done. In this sense, POJO-based frameworks such as Spring (in almost complete opposition to this abused abomination that EJBs turned out to be.)

Why Komogorov's?

Simple. Just do a simple google search. What do you get? Andrey Nikolaevich Kolmogorov, one awesomely intelligent dude. Specifically, it is a bit of a tribute and reference to the Kolmogorov's Complexity of objects, systems and the like. Bear with me for a bit.

The Kolmogorov Complexity of an object is pretty much the amount of resources required to represent that object given a (potentially universally) descriptive language. Since we know we can model all computational systems in terms of automata, or strings in a given language, we can say that the Kolmogorov Complexity of a system is how much it takes to represent the damned thing. If you choose any language, be it Java or what-not, to represent it, that is, to implement a program P that outputs it (or in more general terms, gets it to work), the size or length of that program, the resources it consumes, represents the complexity of its representation.

So Why Then?

Well, it is the case that as our systems get larger and larger, so the complexity of implementing them, or representing them. And complexity is something that cannot be simplified or neglected. The systems that we develop nowadays are intrinsically complex. So far so good.

But here is where we are running amok. With all the technological advances we have made on IT and Computer Science as a whole, it seems that we are getting dumber and dumber with every passing year.

We complicate things for the sake of making them complex. Things that should never have been distributed to begin with are now modeled, forced into distributed architectures, with flagrant violations of anything resembling engineering common sense.

We add, cut and paste and glue together stuff, crap if I may say, using whatever new technical hooplah that is the hot new thing to learn and prostitute - I say prostitute since 'implement' is too grand an adjective to use in this particular context.

Zap XML here, slap JMS there, concoct EJB-based abominations with layers upon layers of fluff, e-fat, binary carcinogenics, all converging into a nonsense singularity that rips the very fabrice of space-time in any non-retarded universe. All for systems that never had any substantial distributed complexity to begin with.

What should have been a Web+App+one-single-database gets exploded like a horrendous, oozing zit to the expense of the customer and to the psychological detriment and violation of those poor IT souls shackled to them by chains of legacy maintenance and eventual intellectual dumbification.


So in a way, the name I've chosen for this blog, Komogorov's p0j0x is nothing more than an accusatory finger (followed by a face-slap) to the horrendous practices of those in the IT sector who, at this time and age, should know better what not to do when implementing a system and charging money for it. In the name of Baal, there is nothing other than human stupidity, mediocricy and avarice that could possibly explain (and yet never justify) it.

Putting aside the politics and challenges that naturally arise in the interactions with business users and customers, some things should just not happen. With all things being equal, developing horrendous code is one of them, specially when done on a regular, self-perpetuating basis. And those of us in the IT sector who have chosen to make a living should strive to avoid that at all costs.

Certainly we do not have a fiduciary obligation to our customers as lawyers and doctors do. But we do have a moral obligation, a moral one, an ethical one, a professional one, to the customers and to ourselves if we really want to deserve be called engineers and if we really have a grain of self-respect and dignity as college-educated professionals.

For the most part, that's what this blog is and will be about.