PNSS, Final Day

Whew, I'm beat. I was sitting in the last session, it was hot, and I suddenly got sleepy. It's been a long
weekend, but it went by really fast. I think this conference is about the right length. I've enjoyed it,
but at the last session I thought "you know, if I had to do this for another day, I'd be sick of it."

Here's the run-down of today:

There were two sessions on Agile Development, given by a guy named Dave. He was a very laid-back guy who had a pretty good approach to bringing the Agile development style into an organization. In short: Be really diplomatic, start slow, and be prepared to lose some battles.

He said something else that I liked: My buddy Dale Cooper and I occasionally talk about what the software development process is like. Cooper likes his analogies, and uses them often. In these conversations, software development has been compared to everything from factory work to home and golf course construction, to interstellar travel in a canoe. At one point, I compared the process to record production, movie making, or the recording of an artistic work. As a musician with a small amount of experience in a studio and various band situations, and it makes sense to me. In both cases, you have a group of creative people who share a desire to create something (and make a name for themselves), you have a budget, you have a collaborative situation where the creative types interface with one another and try to come up with something that doesn't suck, and you typically have a "producer" who "owns" the project and whose function it is to remove obstacles and motivate the creative types to do their best. In all cases, you also have suits sitting around bitching about the creative types who expect to be treated like rock stars, even if they're not.

You also see a lot of situations where someone with a good dose of talent and motivation will do something on their own, create a buzz, get famous, and actually turn into a rock star. They'll have fame and job security until their particular brand of stuff goes out of style or they go West in a pool of their own vomit. So the analogy fits, in my opinion. Cooper didn't seem to care much for it. I'm guessing it's because it places gives too much credit to the creative types, and not enough to "leadership". Which, in his case, is probably a justifiable position to take. In the environment where he's been for the past 200 years, the "creative types" I mention actually are more like factory workers, or they're old tuba players who've found themselves in a prog-metal band and can't riff their way out of a wet paper bag.

Anyway, this guy Dave compared the software development process to the creative process and collaboration that takes place when a band and a producer gets together. That's spot on, Dave.

The next two sessions were kind of interesting. One of them was called "Applied REST", and it talked about RESTful web services. Amazon, Ebay, and several other big companies provide web services of both types, SOAP/RPC and REST. They say that 85% of their web service clients use the RESTful services, leaving a paltry 15% which use SOAP. The reason? According to this guy, SOAP is too complex, heavy, and a pain in the butt to use. REST, by contrast, uses a simple approach that accomodates change, performs well, and follows an easy-to-understand pattern. The summary: REST good, SOAP bad. My own take: REST is, in fact, a heck of a lot more practical for 9 out of 10 applications than the enterprisey overkill that is SOAP.

The second of those sessions was called "Pragmatic XML", and also focussed on web services. The summary there: REST bad, SOAP good. Why? Because SOAP came first. (I guess.. He didn't really say why).

More specifically (and accurately), he went into great detail explaining the folly of trying to use XML to serialize objects, whether you're RESTful or SOAPy. Doing so is an extremely problematic thing to do, especially when you're trying to provide a web service that's consumed by disparate clients (Java, .NET, Perl, Ruby, or anything else that can handle XML).

Normally, I scoff at most of what Microsoft does, since it seems to be motivated by their desire to lock people into using their products, and paying their stupid tax. However, one thing I remember reading in a Microsoft-sourced article about web services made a lot of sense: Quit trying to pretend that live program objects can be flattened into a sequence of bytes, sent somewhere else in the world, and rehydrated into something "live" on the other side. The approach has always worked, but has never worked very well. The older binary protocols (CORBA, etc.) were extremely brittle, and so is machine-generated/machine-parsed XML. A SOAP envelope, a REST document, or a JSON string is a document that describes an object, but is NOT an object. The smart approach is to quit pretending, and acknowledge it for what it is. If you want to serialize XML across the wire, that's great. It works fine, just count on doing something on the receiving end to parse it into what you need. XML isn't the silver bullet to solve the problem.

I'm getting sleepy again.