(yes, this does have to do with web services)

“Travelling through hyperspace ain’t like dusting crops, boy…without precise calculations you could fly right through a star or bounce too close to a supernova, and that would end your trip real quick, wouldn’t it?”
  – Han Solo, Captain, Millenium Falcon

I was folding my laundry the other day, and had the audio commentary for Episode IV on in the background (I get bored with radio, and don’t have cable at the moment). I like audio commentaries because every so often you learn something you didn’t know before.

True Star Wars geeks will know recognize the Millenium Falcon as “the ship that made the Kessel Run in less than 12 parsecs.” I never really understood this line, because a parsec is a measure of distance, not of time. It’s never really explained, but the Kessel Run sure sounds like some sort of race and as such the terms “parsec” seemed out of place. I always wrote this off to George Lucas munging his technical jargon and didn’t think much of it until I actually listened to the Episode IV commentary track where he talks about this a little bit.

It turns out that (at least in Star Wars), getting from Point A to Point B in the shortest possible amount of time is rarely what you really want to do. Sure, it’s really easy to just plot a straight-line course and jump to lightspeed. But if you do that, you’ll more often than not incur some sort of intergalactic trauma along the way and end up at your destination in a bajillion pieces. So the real trick is to minimize the distance you have to travel while steering around all the obstacles that sit between where you are and where you’re trying to go. Doing this in a really efficient way requires a very good navacomputer to do all those “precise calculations” that prevent you from being pulverized. Thus, Han Solo’s boast about being able to make the Kessel Run in less than 12 parsecs was more of a statement about the capabilities of his navacomputer than the size of his engines. I found this to be a very interesting rationalization explanation.

Of course, as I am wont to do, I found myself thinking about the implicit tradeoffs involved here and started drawing analogies to software and distributed systems development. There’s an open question: should building distributed systems be more like dusting crops or more like travelling through hyperspace?

Some people believe that the role of tools in XML messaging stacks is to make the whole experience a lot like dusting crops – that is, the tools should hide the underlying XML artifacts from the end user to such a degree that developers can be happily productive without knowing that things like WSDL, XSD, and angle brackets even exist. This seems like it would be a great thing for developers; They don’t have to learn about these unfamiliar technologies because the tools hide them completely. It lets them get from Point A (the problem) to Point B (the solution) as quickly as possible – which may or may not be optimizing for the right thing. 

Other people think that web services development should be like flying through hyperspace. They know that there are obstacles lying out there in the vast space between connected systems and that simply taking the shortest path from problem to solution might lead you smack into an interoperability supernova. They know that to avoid these obstacles, they need to do some precise calculations – which for them often means hand-writing WSDL docs and getting up close and personal with message schemas in XSD. It’s an approach that gets you there safely, but it’s not going to get you to Kessel in less than 12 parsecs if you catch my drift.

I don’t think you can get around the fact that building distributed systems is frankly a lot closer to travelling through hyperspace than dusting crops. By its very nature, it’s a complex problem domain. Making those complexities go away entirely is pretty much an impossibility¹. I don’t think you can be an effective web service developer without a basic understanding of the what’s and why’s of WSDL, XSD, and SOAP. These concepts are important and contribute to an overall understanding of how the system works – if these concepts aren’t in your mental model of web services, then I think there’s an issue. However, I don’t think that developers should be forced to concentrate on the how’s of these technologies. Being able to hand-author WSDL documents should not be a requirement for building interoperable services. Being able to look at an XSD schema and tell if it violates UPA shouldn’t be a value-added skill for service developers (the world already has a human schema validator, and he’s doing quite well).

I want web services development to be like travelling through hyperspace on the Millenium Falcon. You still need someone to fly the ship, but that job is made a heck of a lot easier by the bad-ass navacomputer sitting in the back of the cockpit. On the Microsoft platform at least, that navacomputer is Indigo. I don’t think the goal of Indigo is to allow you to remain blissfully unaware of the existence of the underlying XML technologies. Rather, I think the goal is to dramatically reduce the level of concrete understanding you need to have about these things in order to be a productive user of the platform. WSDL, XSD, and SOAP are facts of life in the web services world, and you have to understand those things on some (hopefully high) level to be a successful services developer. However, acknowledging their existence is very different than knowing their inner workings. That’s where a toolset like Indigo can add a lot of value and remove a lot of complexity. Developers should focus on the what’s and why’s, and leave the how’s to the tools.

Update: William's got some good background as to the origins of this rather sideways metaphor here. It all stemmed from IM convo I had with him where he made the statement that "companies just want to get from Point A to Point B as quickly as possible", to which I retorted "well, travelling through hyperspace ain't like dusting crops, boy...". After a couple of additional conversations with TShak on the way to and from our friend Mike's place on the hood canal, this is what resulted...