Friday, October 24, 2008

thought interruptions are life's choppy video

The other night I was watching the Daily Show through hulu.com in a hotel that had a slow internet connection. About 10 minutes into the episode, the video started getting choppy. I tried ignoring it, but even though the chop occurred only for a split-second, and happened every few seconds, it was distracting to the point where I couldn't watch the show any longer. Everybody knows what that's like. It's the same thing with a slightly scratched DVD. You could theoretically keep watching, but there's something profoundly interrupting to that lack of continuity.

That's the best layman's term analogy I can think of for what it takes to perform a job that requires a deep level of sustained thought. Many have studied and written about this. Some call it flow, some call it getting in the groove. The latest prose in my field is by the gifted Neal Ford.

I make software for a living, which is a field that has a very difficult time quantifying the things that matter about it. Examples at a low level are this:
How do you quantify good code? How do you quantify a good programmer? To this day, it still takes a good programmer to tell them apart - no untrained eye or machine can. The need for uninterrupted thought is another requirement that's easy to overlook and communicate, yet it's absolutely critical to making quality software.

And oh yeah - a faster hotel internet connection. That too. :)

Tuesday, October 14, 2008

The CDATA board of education

During my days on the web services team of a big bank a couple years ago, we wrote a ton of web services on the java platform. Almost every service we wrote was SOAP based, and also conformed with a huge pile of enterprise standards that were actually pretty non-standard in the outside world.

The consequence of these slightly non-standard services were that first-time clients of our services sometimes had painful integrations with us. Most notably .NET clients that wanted to auto-generate their client proxy classes. The tool would simply not work with our WSDL, so they had to manually bind to our services, which greatly increased their cost and dates. We didn't care though - the services we wrote were compliant according to our tools, and we simply didn't care that much about the clients that were having trouble connecting to our services. Suck it up, you whiners. We hand wrote all our services from the contract on down, and we're not going to bend over backwards for some whiny .NET'r that can't step outside the confines of his "Add Web Reference" tool.

Fast forward to the last few months. I've written client code for four different service providers. One SOAP, one TCP (I didn't know people still wrote raw TCP-based services!), and a couple XML over HTTP services.

The integration that made me shameful of my former attitude was one of these XML "services" that consists of a large amount of non-normalized CDATA. For example:


<[CDATA[
ColumnHeaderA ColumnHeaderB ColumnHeaderC
aaa bbb ccc
ddd eee fff
ggg hhh iii
]]>


My attitude was that any self-respecting programmer would not be serving up text data that should not be parsed by the XML parser and pass it off as a service, forcing clients to use regular expressions when they should instead be using a proper XML parsing tool. The product manager couldn't understand why I felt that this service was no friend of mine. Their opinion was that it was a perfectly good service, and any average programmer could crank it out in a week.

Why? Because they wrote everything in perl!

It caused me to think back about those clients that I've wronged by not making their lives as easy as it could be. Not to mention gave me another anti-pattern to look out for.

Words of wisdom? When writing a public XML service, do eat your own dog food using different platforms and techniques to evaluate the palatability of your service. Also, write client code for a few other public services to see what feels good, and what's painful from the client's perspective. For example, do you really need to namespace your XML? Does SOAP make it harder or easier for what you're trying to offer? You might be surprised by what you find to be elegant from different sides of the service.

Want a survey? Don't ask!

Here's a suggestion when you create a survey for your site:
Don't ask for permission - just show the survey.

Meaning, don't pop up a window after the user's completed their shopping, asking them if they wouldn't mind taking a minute to fill out your survey. This is synonymous with telemarketing, and makes most people cringe.

If your survey is really short and to the point, present the survey right then and there. You've already popped up the window. Give them a couple radio buttons at most, and the all-important open comments field. That's where you'll get the most useful responses.