This is the first in an on-going series of posts in which I will explore application complexity – what it is, some of its different sources, and ways that we can reduce it. But first, I want to take a little time to mention that some application complexity is actually a good thing …
If 
you are a fan of J.R.R. Tolkien and the various middle-earth tales (Lord of the Rings, The Silmarillion, etc.) then today is a great day … the release of The Children of Hurin, the first new book by J.R.R. Tolkien since, well since the last book that he post-humously published. While you may be thinking “hey I knew this guy was a good writer, but how did he ever figure out to publish more books after he died than before?”, and that would be entirely fair, it doesn’t matter here – this is still a great day!
One of the key attracters to the world of Middle Earth is it’s sheer complexity, its breadth and scope, all interwoven with surprising coherence. Four ages, continents that come and go, races that rise and fall, a bunch of new languages, it’s all there. And more. Far more.
That’s what makes the release of a new book that sheds some light into part of this cosmology so exciting – more detail to enjoy, more adventure to learn. In short, more complexity.
But this sort of complexity is a good thing.
It’s complexity in the things that people who care about Middle Earth care about. It’s the equivalent of the good stuff that a given application is supposed to do for the enterprise that deploys it. After all, FedEx actually wants to keep track of packages while it delivers them on time, and wants to keep track in ever more detailed, reliable, and useful ways. Visa wants to accurately authorize credit cards, the iTunes store actually wants to deliver and bill for song & movie downloads, when expected, in the quality in which people want to watch them. GeoEye (a successful operator of commercial satellites) wants to operate their satellites well & process the images quickly and accurately. And so on and so forth … after all, we build and deploy computing systems to do useful things.
The problem comes in when, in order to do these useful things, you have to take care of all of extraneous stuff that is only their to ensure that those useful things are truly useful … that the enterprise can count on the application to be reliable, scale as needed, and be cheap to operate. Then all of the extraneous complexity that is so persistently part of most everything the industry has been building to date simply gets in the way.
That’s when a client’s or executive’s eyes glaze over, or their blood pressure pops, or their head hits the table. Mind-numbing detail that they don’t care about, causes problems, and costs money … but other than that it’s fine!
Imagine if Tolkien had spent the first 50 years of his life working out the physics of Middle Earth to the sub-atomic level, then worked out the “Uniform Commercial Code of Elvish Commerce”, then went on to relentlessly pursue the Elvish Genome project. While I’m sure that future Elvish races would have been indebted, not too many human readers in our world would have cared too much. And Tolkien definitely would never have gotten around to creating the Lord of the Rings, and there where would we be?
That is exactly what happens to so many computing systems. We gut stuck in the mud, fascinated or blocked behind details that don’t have too much with the actual purpose of that system.
Tolkien did a brilliant job of creating just enough of the complexity to give him a coherent framework for the worlds, peoples, and stories that he really wanted to create. That is both the challenge and opportunity before those of us who care about building, deploying, and operating computing systems and applications.
Stay focused on the what those systems need to do and ensure that they do it well … and forget about the Elvish Genome Project.
Technorati Tags: application+fabric, complexity, commoditization, tolkien
Comments on this entry are closed.