Thursday, December 11, 2008

Conferences in Emerging Tech Countries

I speak at lots of conferences in the US and Europe, and they pretty much have the same feel (modulo different languages, both programmer and spoken). But I also speak at a few conferences in emerging technology markets, like my recent conference appearance for JAX-Asia, a Java-centric conference that happens over the course of three days in Singapore, Kuala Lumpur, and Jakarta. Attendees at these conferences are very much like attendees at conferences elsewhere: slightly geeked out, interested in learning about new stuff, and inquisitive. They also exhibit a lot of enthusiasm: there aren't as many conferences there as here, so going to a conference is a bigger deal.

I have two observations from my recent trip. I first observed (with the help of my colleague, Erik Doernenburg) that all the conferences in Asia have lots of sponsorships. Generally, attendees pay very little (if anything) to attend the conference; most of the cost is offset by vendor sponsorships deals. But along with the booth in the exhibit area, vendors get one or more keynotes. Now, I don't want to completely denigrate vendor keynotes. I've seen a couple that had actual content, not just blatant marketing. But, for the most part, the mode in Asia seems to be outrageous over-the-top marketing, making them not so much keynotes as "marketing-notes". Because most of the attendees aren't yet jaded and cynical, they stick around for the marketing-note, succumbing to the danger that their marketing bullshit detector is not as well honed as ones in the US and Europe. They might actually believe what this vendor is saying about SOA -- what a frightening concept! To their credit, the conference also books in regular sessions that offset some of the damage caused by toxic marketing-notes. One of my talks at JAX-Asia was my Evolutionary SOA talk, which is pretty much the polar opposite of what most vendors say about SOA. One of the reasons I like speaking at out of the way conferences like JAX-Asia concerns around this very issue. I'm very interested in providing my (and ThoughtWorks) perspective on technology and methodology to offset the message of people just trying to sell something. I genuinely want to advance the state of software development, which has no geographic boundaries.

The second observation from JAX-Asia is the span of sophistication of the attendees. Just like any conference, you get a fair number of wide-eyed innocents, who just discovered Ant last week and want more cool stuff like that. To those attendees, preaching about dynamic languages and other cutting edge stuff is pointless: their primary interest in the conference is shoring up their current development practice, not spelunking into the future of technology. But it's a mistake to assume that all the attendees are beginners. Like any conference, a wide variety of skill sets and experience show up. For example, for JAX-Asia, I did a talk on JRuby, and another comparing Groovy & JRuby. JRuby was one thing: at least a few of the attendees had heard of Ruby. But the comparison talk was brutal on both me and my audience. No one had even heard of Groovy, so discussing the nuances of the differences between a technology represented by a word they had heard ("Ruby"), with another technology for which no one was familiar ("Groovy") was tough. Yet, generalizations are dangerous. After my talks in Jakarta, I was chatting with one of the attendees, who turns out to be the president of the Ruby users group in Jakarta, which has 50 members! To me, this shows two things. One, never assume that the crowd to which you are speaking in homogeneous. Even if the majority are novices, chances are good that there are some experienced developers there as well. And, two, Ruby has managed to penetrate pretty far and wide. A 50 person Ruby users group in Jakarta encourages me greatly because it shows that the foothold that dynamic languages have in the US and Europe is spreading to other parts of the world.

Monday, December 01, 2008

Irrational Artifact Attachment

The lowly whiteboard is one of my favorite tools for design work on projects: you can stand in front of it as a group, you can easily play "what-if" games with emergent designs, and you can argue until everyone agrees (or at least until everyone is equally unhappy). Once you've got it done, a quick snap with a digital camera and you've got a project artifact, ready to post on a wiki or similar until supplantation by actual code. Once you have real code, you are better off allowing the design to continue to emerge from it rather than trying to keep the two in sync. Alternatively, you can use a reverse engineering tool to produce a prettier version of the original diagram from the code.

I prefer this low-tech approach to the more formalized version using tools (from drawing tools all the way up to really formal tools like Rational Rose) because of the proportional relationship between a person's irrational attachment to some artifact to how long it took to produce. If you create a beautiful UML diagram using some tool like Visio that takes 2 hours, you have an irrational attachment to that artifact that's roughly proportional to the amount of time invested. That means that you'll be more attached to a 4 hour diagram than a 2 hour one. By "irrational attachment", I mean that it's harder to listen to reason as to why it's wrong because you know how much time it took to create it (and therefore the required effort to update it).

This applies to pretty much any software artifact. I've seen this effect for design documents and diagrams, architecture, requirements, use cases, and database schemas. This suggests that really elaborate tools favor one-shot designs, where the pressure is on to get it right on the first pass. Of course, you can change it, but how much willpower exists to do that? One of the benefits to the low-ritual approach to much of agile software development revolves around creating "just in time" artifacts, with as little ceremony as possible (this helps explain the dedication to lots of agilists to index cards and sticky notes). Using low-tech tools frees you to throw away what's not right, freeing you to experiment and allow the true nature of the artifact emerge through revision, collaboration, and discussion.