Some thoughts that popped into my head during my recent trip to Hawaii:
Hawaii is, as far as I can tell, pretty much overrun by tourists, and thus you often had to look at somewhat hard to find people who are genuine. I guess the experience that stands out the most was a sailboat ride we took. The skipper, who had clearly done this trip hundreds or thousands of times, had his script memorized: he had a snappy comeback for every question, which he half-heartedly delivered. Were the jokes funny? Yes. But there just wasn't any sort of personal connection, mostly because it didn't feel like he was real. Now, I'm not so naïve to think that being authentic in this situation is easy, but I do believe that it is possible and ultimately vital for successful user experiences.
I contrast this with another tour we took, this time at Surfing Goat Dairy. Two German ex-pats run this very nice little goat farm in the middle of Maui, and they offer tours and tastings. I'm sure they've been through plenty of tours in the years they've been open (but probably less than the 3-a-days the boat skipper did), but it didn't feel like it. It felt like we were talking with actual humans, and knowledgeable ones who took pride in their work. And the tasty cheese helped, too.
It is so important, no matter the situation, to be authentic with those you work with (both inside and outside your organization). People can smell spin and obfuscation a mile away. Be straight with people, and they'll appreciate it.
With some types of projects, the best approach to take is to focus on continuous improvement. We stayed for a night at a restaurant and inn called Mama's Fish House. In the room, they provided a copy of Maui Magazine, which, coincidently, featured an article about the establishment's owners (I'd link to it, but Maui Magazine doesn't have it's archives online). (Update: the article is now online.) The owners have employed a carpenter/designer for nearly the entire 30+ lifespan of the restaurant, and in that time this craftsman has slowly built out the building into a very impressive space. He mentioned, I believe, that they'd re-done every wall in the place at least twice. Basically, they started small (with a little hut), and built slowly built it out over the years.
Excepting the type of project where you either need to make a big splash quickly, or launch at a very large scale, the continuous improvement tactic is the one to take. This is the sort of approach we take on things like websites. Good websites are never done, and always "under construction." Sure, there might be periods were you do fairly major re-models, but mostly you want to instill the idea that you can always make small tweaks and changes to make it better. This approach also gives you much more flexibility to change as conditions change around you. You can address problems as they crop up rather than trying to initially plan for many contingences.
I think the difficulty of pointing a group of people in the same direction can be reduced to a simple mathematical formula:
Difficulty = n2, were n is the number of people in the group.
Needless to say, this really only applies to situations where people have the free will to choose the direction they want to take. But, this little formula should be kept in the back of every project manager's head, and factored into schedules and other project activities.
Don't invest in airlines. I won't bother recounting the 30+ hour Seattle-to-Maui travel nightmare, nor will I name specific airline names, but I can't help but notice that all is not well in this industry. Admittedly, this isn't exactly earth-shaking news, as the financial difficulties of airlines (not counting low-cost carriers like Southwest and JetBlue) is well know. Peter Merholz recently ranted about airlines and Victor Lombardi has some good observations on JetBlue, so I won't cover any ground they hit in their respective rants.
My observations fall to the airline's computer system. I'd love to get a look at the reservation and booking systems, because from my perspective as the guy across the counter, something is deeply wrong. It seems to take an inordinate amount of typing to handle even the most basic task (checking, seat assignment, and so forth). And making flight changes takes a wild amount of time. Because of the aforementioned travel nightmare, we were able to make some changes to our return flights (extra day stay, direct return flight). It took the agent a really, really long time to make the change. The kicker is that the agent didn't even manage to do the process correctly, even after 15 minutes of tapping away on his terminal. Nearly every time we needed to interact with someone, the first person who tried to help couldn't. Sometimes you'd see two or three agents pointing to the screen and giving advice and hints to the one typing. I'm pretty sure that no computer system should be this hard.
I'd really like to see an article about the computer systems the airlines use, just to learn more about it. I'm betting that this is a system that has evolved from 1960s-era Sabre system. If you've seen any write-ups on the usability or history of these systems, let me know.
A couple of noteworthly things I've seen lately:
Joe Gregorio's Sparkline generator cgi and webservice. This implementation, done in python, joins a number of other sparkline generators. Cool.
Chris Campbell's Preview Your Links with Unobtrusive JavaScript. This looks like an unobtrustive client-side way to plop little icons next to links. Probably not right for all situations, but nice anyway.
So, I'm back from a week-and-a-half vacation. I didn't touch the web, email, or very many other hi-tech gizmos during this period. Contrary to predictions, I didn't get the shakes or exhibit any other outward signs of withdrawal. I am, however, fairly buried under the stuff that stacked up while I was gone. I have a fair number of emails (both home and work) to crawl out from under, and thousands of RSS items to read. In this situation, some would argue for just marking everything read and starting fresh. I just can't bring myself to do that (well, it was never an option with the emails, more so with the RSS), fearing I'll miss some good stuff. And, as I slowly make my way through the list, I have found many a nugget of goodness:
Well, I have about 300 more unread items to go, so I'll probably hit more good stuff.
Okay, so I've been banging away on this little one for three or four hours now, to no avail. I'm hoping maybe a python expert sees this and can help. Here's the story:
I'm working on a little python script that will grab search results from one of our vendors to include in a federated search system. I've had pretty good results with most of the vendors we work with, and all in all, my little program is pretty slick.
But, I'm stuck with one of them. You see, in order for their authentication system to work when I'm doing the search, I need to first get a cookie with a session variable from their server. So, it needs to look like this: hit homepage, get cookie, send second request, get search results. Pretty easy, huh?
Turns out, no, it isn't that easy. The root of the issue is that my script is including the "Connection: close" HTTP header. And when the server (IIS) sees this, it flushes the session variable it set. So, on the inital request, it gives me a session variable then immediately flushes it. Not so useful.
So, I need to not send the "Connection: close" header, so that IIS will keep the session alive. Fair enough. Let's look at what I'm using to grab the scripts. Plain old urllib and urllib2 won't cut it, as they don't have cookie support (well, urllib2 got it as of python 2.4, but our box is running 2.2, and I'm pretty sure that wouldn't matter anyway). So, I'm using ClientCookie (which eventually merged into the standard library as cookielib). ClientCookie is pretty darn slick, very easy to use. But, you guessed it, no persistence. It sets the same old "Connection: close" header as urllib2 does. So, I then turned to urlgrabber's keepalive module. This works like a charm...easy persistent connections. But, uh, no cookie support. Both modules let you set headers (to change the User-Agent and such), but my attempts to change the "Connection" header go nowhere.
I have two different problems, with two solutions. Just they won't work together. I've spent a few hours trying to combine them without luck. The next thing I can think of is to basically try to re-write the functionality of these two modules together as one, but that sounds really, really ugly for this occassional programmer.
Anyone out there a python guru with a good answer to this?? Write me!!