Communication Channels & Cell Phones

I noticed the other day that lots of states now ban talking on cell phones while driving, yet they don’t outlaw talking to a person sitting on the seat next to you. Why is that? I have a suspicion: talking to someone on a cell phone takes a lot more concentration. Many studies place accident rates for drunk drivers and cell-phone talkers evenly. The implication is that talking on your cell phone robs you of as much concentration as drinking!

But my experience with software development bears this out. I’ve worked on several geographically diverse projects, where the communication channel is reduced to phone calls in conference rooms. This is a terrible communication medium because you can’t see the other people, can’t see their facial expressions and body language, and don’t understand the subtleties of their vocal inflections. Humans are social animals (even developers who don’t interact well with other humanoids). We don’t realize how much we rely on those non-verbal communication channels until we notice how much concentration it takes to talk on a cell phone in a car.

Alistair Cockburn has a great diagram in his book Agile Software Development.

He has modeled communication effectiveness to temperature dispersal from a heating source. The further away from the source, the colder you are. This is a great metaphor because it takes into account the subtle communication channels upon which we depend but don’t realize are there until they’re not.

The importance of this for software development shouldn’t be ignored. If you engage in distributed development, insist on warmer communications, like video conferencing. Even Skype video, while crude sometimes, beats the phone-call-in-crowded-conference-room anti-pattern. On one of my projects, we had serious cross-ocean communication gaps because we’d never met in person. The results aren’t surprising: personality clashes, misunderstanding about technical problem resolution that cost us time, and general stand-offishness between the teams. Wisely, my project manager invoked the XP “Move people around” principle, and we shuffled developers from the US to India and vice-versa, for a couple of iterations each. This was on a fixed-bid project, so we incurred the cost for the travel ourselves. And it was the best thing that ever happened to the project. Once you’ve met people and spent time with them, it makes even conference call communication better, because you can pick up on subtle clues in people’s voices that indicate a facial expression you’ve seen for yourself. One of the developers on our US team was widely loathed by the developers in India (so much so that, when I went there, they had drawn an “X” over his face in the team photo we had on the wall!). But, when he went there himself, he became fast friends with many of the developers. Some personalities must be experienced in person before they are tolerable, especially to different cultures.

So, the next time you are driving and talking on your cell phone, do 2 things: keep an eye out for the police in your rear view mirror, and notice how much more mental energy it takes to talk on the phone rather than to a person sitting with you. This to me is the proof that Cockburn nailed it.

Seoul Observations

I have a cool job. The opportunity to travel to interesting places is one of the coolest parts. Recently, I had the chance to go for the first time to Seoul, Korea, speaking at the Entrue Developers Conference.The conference was very well organized, but it was a conference like any other. The interesting things for me were the observations I made while I was there.

First up, phones and Internet. I proudly carry an iPhone (one of the first purchasers, don't you know), and smugly rub it in the face of all the poor phone 1.0 owners. In Korea, their cell network is far more advanced than ours. So advanced, in fact, that they aren't even backwards compatible with our phones. None of my other co-worker's phones worked either, except the one that had a special phone for Korea. The other notable technology difference was the speed of the Internet connections. The Internet in my hotel room was one of the fastest I've ever used! Stuff that takes 45 minutes to download here takes 7 minutes in Seoul. Unfortunately, I didn't actually measure the speed, but it was blindingly fast. And that was just my hotel room connection!

Second, business in Seoul is much more formal than here. Before travelling there, I asked my co-worker from China meeting me there about the dress code. I try to remember to do that when I travel so that I minimize the ugly Americaness that leaks through anyway. He said "Oh, don't worry -- it's business casual. Slacks and button up shirt is fine." Well, I get there, and I'm the only one there without a suit. One of the nice things our host did for us was an invitation for a lunch with about 200 corporate CIO's in Seoul. My co-worker (the same one who advised me) leaned over and said "See that guy over there -- he isn't wearing a suit, so you aren't the only one." Thanks! In general, business is much more formal. Developers wear suits and ties to work, which is increasingly rare here.

Third, I was asked to give a presentation at one of the local companies, to their enterprise architecture group (SOA is big in Korea). The only snag: they don't speak english, and I don't speak Korean. The local guy there who invited me to speak at the conference volunteered to translate for me. This was a first: I would discuss the contents of a slide or example, then pause while he translated the entire thing to Korean. He was extremely knowlegable about technology, so I have high confidence in his translation. It was just weird: speak, pause, speak, pause...for almost 2 hours!

Fourth, they have different technology priorities there. While a lot of big companies in the US have embraced the run-away accidental complexity that is SOA, they have taken it to a manaical level. We sat through a presentation of an SOA Goverance Framework. They have every detail nailed down to the tiniest degree. It looked great on paper, but it was absolutely unworkable in the real world. Can you really tell the business that they must slow down their pace of innovation because the SOA goverance framework keeps all IT at a snail's pace? Developers spend more time filling out forms and consulting the thousands of pages of documentation on how to govern their SOA than they do actually writing code. I asked during the presentation how this impacts the business and got blank stares: business? What does the business have to do with our enterprise architecture? It was the most elaborate, meticulous, detailed, unworkable framework I've ever seen.

My fifth observation is the dichotomy of their IT priorities. On the one hand, they've embraced SOA (particulary the bad parts, in my opinion) whole-heartedly. The important priorities for their enterprise development seems to be to lock down all variability (and therefore flexibility, evolvability, and adaptability) from their enterprises. They have state of the art SOA fetish there, building meta-SOA frameworks. Yet, you ask them about some of the things considered interesting in the states (like the rise of dynamic languages), it's not even on their radar. It's not that they have looked at it and disregarded it. They haven't even heard of most dynamic languages. Ruby? Groovy? Python? The only one they've even heard of is Perl, and they have a poisionous disdain for it. They have of course heard of JavaScript, but it's a toy language for visual effects in browsers. They treat it like an extension of CSS.

Of course, the best part of traveling is the people: I met so many friendly, gregarious, funny, open people there. We had several great meals, lubricated either by fine wine or Soju, the Korean version of Sake. It's wonderful stuff: it tastes like mild Sake, but it packs almost the punch of vodka. We talked about lots of stuff, both technical and non-technical. The last speaker's dinner had geeks from Korea, the US, China, Japan, Singapore, Malyasia, and lots of other places. Travel does indeed broaden you, often in unexpected ways.

So Many Conferences, So Little Time...

Lots of people know me from the conferences where I speak. If you only see me at Java conferences, you probably have the impression I'm primarily a Java guy. But I have a great love for lots of types of technology. Languages and platforms are just tools, and you can build effective software in all the major platforms. Which is why I set out with an informal goal this year: speak at the major technology conferences for each of the three technologies I follow the most closely: Java, Ruby, and .NET. And I succeeded! As far as I know, I'm the only person on earth speaking in rapid succession at JavaOne, RailsConf, and TechEd (in that order).

This isn't just a vain pursuit. One of the reasons I love working at ThoughtWorks is the experiment of doing agile software development at the enterprise level. To do that, you need an understanding of the major technology stacks in play. Yes, I love Ruby and Ruby on Rails right now, but there are times when the appropriate choice for the client is a Java and/or .NET solution. In fact, I think that being able to compose solutions with languages on platforms is an important trend. I want to understand technology divorced from hype and religion, leaving just the efficacy of the platform in place. Our challenge is understanding how to best leverage the platform to meet the business needs for that application and that customer. And that's plenty challenge enough.

Trippin' with TripIt

Let's say you were traveling to Chicago back in 1990, and you wondered about the weather during your trip. How would you find out Chicago's weather? Well, you could turn on the Weather channel and wait for Chicago to come up. Or, some national news will have it, but you have to catch it just at the right time. Or, if you really needed to know, you could go to a library and look at a newspaper. There were also call-up services you could call and get the information. It was such a hassle, though, that you would probably not bother, especially if you already had a feel for what the weather is like for a particular time of year. The Internet changed that. Now, it literally takes me less than 15 seconds when I'm at my computer to get a 10-day forecast for Chicago (or Singapore or Jakarta). The Internet makes things so easy that you'll actually do them. While getting the weather wasn't impossible, it was such a hassle that it was discouraging.

Fast forward to now. A while back, a friend invited me to Dopplr, a social networking site for travelers. It allows you to see when the other people in your social network are nearby. Great idea, and useful service, but the duplication of data was bothersome for me. My calendar is already incredibly complex, and keeping another calendar up to date didn't appeal to me. I decided to wait and see if you could point it to an iCal instance or something, which would ease that pain.

Then, TripIt came along. TripIt is a new web application that helps manage your travel. Here is the scenario. Let's say you are going on a trip to Des Moines. You book your flight on Delta, a room at the Marriott, and a rental car from Avis. Each of them sends you a confirmation email. In the past, I had an editor template set up to enter all that information (confirmation numbers, addresses, etc.) so that they would be consistent, and I harvested the disparate information myself. That's where TripIt's genius comes in. They parse standard confirmation emails from airlines, hotels, car rental companies, aggregators (like Orbitz), and even travel agents and build a standardized itinerary for you. When you get the confirmation email, you just forward it to plans@tripit.com and it automagically does the rest. It builds a nice itinerary, with airline checkin links, a link to SeatGuru with the type of plane already selected, a map of your destination city -- basically, everything you need to know. That's nice and painless.

But it gets even better than that. TripIt maintains an iCal instance for you, to which you can subscribe with all your travel details. So, here's my new workflow. I have forwarding rules set up for the airlines and other travel services I frequent to automatically forward the confirmation to TripIt as soon as it hits my inbox. I book travel, and that's it. Five minutes later, it shows up on my calendar, organized beautifully. And remember Dopplr? It will also allow you to see when friends are close and let your invited friends see your itineraries (on a case-by-case basis -- you can share specific trips with friends). It does what Dopplr does without Dopplr. TripIt took the good idea of Dopplr and supercharged it.

TripIt is an awesome combination of travel service, social networking site, and personal travel information manager rolled into one seamless whole. It is one of those services that you instantly wonder how you ever lived without. In the past, when I knew I was going to be in the same city as a friend, we would email exchange our itineraries. Now, we just share them on TripIt. It's so easy, it's trivial to do, like getting the weather, so it's much more likely to happen. For some social networking sites, you have to experience it before you understand the attraction (like Twitter). TripIt has no such grokking curve: I instantly knew that it was going to be an important improvement to my workflow, with social networking goodies thrown in for free.