NullPointerFactory

A year or so ago, I coined the term Software Hippie, meaning someone who wants to “make love, not contracts”. Prominently among these “hippies” were the REST crowd, the people who wanted to use the same few operations to send all sorts of undefined ungodly gobbledegook over the wire. I reveled in the comforting concreteness of WSDL. With WSDL, we know exactly what we’re sending, we know exactly what we’re getting, we’re declaring all the assumptions up front, instead of hiding them deep in the bowels of our code. Splendid! So, um… what happened?

Well, there is the the fact that you can use MIME types to declare the complete structure of resources, if you so desire. And there is that pain in the aft section when trying to serialize and deserialize complex objects to make them look portable - but I knew that a long time ago. What really let me down was my beloved WSDL:

I love contracts. I like stating assumptions upfront, and being as draconian as I can about forcing everyone and everything to live up to those assumptions, or to rage most bombastically if these assumptions are not met. But after having to actually implement things that both create and consume WSDL, I’ve come to realize that there is another extreme: overspecification. Let’s suppose I have a classic SOAP service that provides employee records, and I have a client that wants the name of an employee with a given ID. That client would have to be built against a WSDL that specifies much more than the client needs to know. That renders the client coupled to a whole bunch of definitions it doesn’t need. How much neater is WADL - it just tells you where in the response blob to get what you want, and you can happily ignore all the rest. Now, this problem can be somewhat avoided by keeping operations and their data types very fine-grained, with all the aesthetic and performance detriments such a reduction portends.

But the plot gets even darker when the excessive contract is meant for human, not machine, consumption.  Think of the SOAP spec (1.1 or 1.2, your choice). That thing is f*****g huge! And unlike machines, when faced with a task as daunting as implementing such a gigaspec, humans are strongly tempted to do a half-as*ed job. That’s why two SOAP stacks might have trouble understanding each other’s SOAP messages. And let’s not even get started about all the “optional” features and all the normative and non-normative usages. I think it’s safe to postulate that consistency among contract implementations varies inversely with the size of the contract. Once a contract gets huge, the probability of inconsistency among any two implementations gets quite high.

So that’s my main beef with the WSDLs and the SOAPs of the world. Good things come in small packages. Why should contracts be an exception?

Completely off topic, I want to mention the recent Disney-Pixar release Wall-e. That movie scared me. And not just because of the gaping plot hole where Wall-e’s video tape has two songs from Hello, Dolly right next to each other, even though they’re on the opposite ends of the real film. No, it wasn’t even because of the film’s environmentalist or Neoluddite morals. No, it was because of the Axiom - the cruiseship in space.

I’m scared, because I love cruise ships, and yet so much of the film’s portrayal of cruise ship passengers is accurate. Certainly there’s the eating all the time. One almost feels cheated if one does not stuff himself to or beyond one’s maximum intake capacity. I’m sure if most of us lived on cruise ships, we’d be looking like the Axiom passengers in no time. Then, there’s the laziness. Lounging in the sun all day, with a waiter always handy to bring a drink, taking the elevator even when one must traverse only one deck… and passengers in balcony suites can happily just sunbathe without leaving their rooms, with room service happy to deliver another meal at any hour of day or night.

And if you have any doubts as to whether cruise ship passengers are as insipid and simple-minded as those on the Axiom, just ask any crew member of any cruise liner, especially a liner that serves American passengers. They’ll be more than happy to regale you with stories of passengers asking whether stairs go up or down, or how to tell which photo in the photo gallery is theirs. They even have a name for passengers - “cones”, after traffic cones, or things one must maneuver around.

For a long time I dreamed of living on a cruise ship. I mean really living, not working as a crew member (i.e. sleeping on a bunk bed in a broom closet, eating at fixed times during the day, answering the same stupid questions week after week, etc). Some people actually do get to live on ships. But I wonder, if I had that opportunity, would I not slowly deform into the human Michelin man that the Axiom passengers have become? Wouldn’t we all?

I was browsing around the tech book section of Barnes & Noble last weekend - just seeing if anything would pique my interest. And something did: a wonderful essay by Martin Fowler demonstrating various internal DSL techniques. The essay was in The ThoughtWorks Anthology. Sadly, though, the essay and I could were not to forge a long and tender computer-side relationship, because the remainder of this almost-$40-volume (at least based on a two-minute flip-through) seemed like the typical holier-than-thou “always test” and “use CI” preachery that seemingly hangs off the tip of every other ThoughtWorker’s tongue.

Having bought two other anthologies under the Pragmatic Programmers brand (the two No Fluff Just Stuff volumes) I’m starting to notice a familiar strategy – distill two or three strong hits, fill the remaining space with fluff, and make people buy the whole thing or nothing at all. That’s right – just like the music industry circa 1995. And we know how that cookie (or business model) crumbles – with middle fingers held high toward the record labels, customers flocked to Napster & friends, and gave the industry a simple ultimatum… either we buy what we want, or we buy nothing. Today, ITunes outsells every other music reseller in the US – thank God the industry listened.

Pragmatic Programmers have the same thing coming to them. If they think the task of finding their books on P2P networks bears even a modicum of difficulty, they should slap themselves silly for their ignorance. Don’t get me wrong – I neither commit nor encourage piracy of any kind. In fact, I’d love nothing more than to pay a few dollars for Fowler’s essay. Will they take my few dollars? Or will they follow the music industry’s late nineties collision course and get nothing?

For a while now I thought that after a few more years as an engineer I’d try to become an instructor or an evangelist of some kind. At every class, symposium, or product launch I attended, I kept thinking how great it must be to be one of those people on the other side of the podium. Traveling around, meeting new people… it all seems like a bright contrast to coming into the same cubicle and the same people every day, however great those people and that cubicle may be. Besides, I adore PowerPoint with a burning passion… it’s a love affair I carry since junior high… I always got a kick out of doing presentations ever since I stopped sweating from stage fright in front of a classroom. As of three days ago, a shadow of doubt overcast this ambition.

This past Thursday I did a presentation in front of a group of complete strangers. To be sure, I made many mistakes that I will not repeat:

• Taking a presentation designed for one audience and transposing it onto a different audience without adjusting for the difference in the audience’s background and context. A critical step in the preparation of any human-oriented deliverable, be it a presentation, a document, or even a piece of software, is to become one with the audience: to learn what the audience knows, and to forget what it doesn’t know.
   
• Failure to pre-designate “martyrs”. A “martyr” is what I call a topic area that will be sacrificed if the presentation becomes slowed due to audience participation or the need to dwell on or clarify another point. Once identified, martyr topics together with martyr slides must be moved toward the end of the presentation while, hopefully, maintaining some semblance of a coherent narrative.

• Failure to wrap quickly when I noticed the audience interest wavering. Some nugget of information at the end just seemed to interesting to chop it off. It’s a challenging balance between wanting to end with a bang, and slipping the martyrs toward the end where they can be quickly done away with.

But there’s one truth that will remain in spite of how good a presenter I become… At work, I have a very warm, jovial relationship with all of my colleagues. Anyone who’s known me for longer than five minutes knows that I have no qualms about sacrificing my dignity to elicit a laugh, and so in a familiar environment all sorts of little gags and self-deprecating kernels of insanity are allowed and welcome… that’s what makes it fun. In front of strangers, however, this just does not work… they can’t tell if I’m goofing off or if I should be taken away by men in white suits… In a technical presentation, people expect distilled technical content - everything else, is a distraction. That took some air out of me.

There are exceptions, I think. Keynotes and meta-technical presentations allow room for some occasional frolic. When audience members don’t exactly know what they came to hear, they’ll grant much more leeway. Also, I noted earlier my failure to develop more common ground with the audience in advance of the talk. Perhaps on that common ground, some seeds of amusement may blossom. In the meanwhile, the only answer is to try again…