Meme Agora

The iPad: the Good, the Bad, and the Ugly

2010-06-09T16:32:00.007-05:00

Disclaimer:
I'm a hard-core lover of Apple products; between my wife & I, we own 4 Macs. However, I also hate Apple's stance as a company on lots of topics. In fact, I would probably never use their products if they weren't so damn good. I'm just disclaiming that I may not be objective (although I try to be).

I was not one of the early enthusiasts for the iPad when it was first announced. I did not pre-order one and really had no interest in one until I had a chance to touch one. It didn't seem to make a lot of sense for me: I split my time between my laptop and the iPhone (which I truly love). The iPad didn't seem to offer much that I didn't already have.

But I realized in the first 10 minutes of playing with one that I was looking at the first incarnation of the next platform, and I quickly ordered one (actually, 2 — one for my wife & one for me — like the iPhone, I knew she would never wait for a hand-me-down). This blog is a culmination of my thoughts and impressions.

General Thoughts

It doesn't take long using an iPad (especially if you've been to the Apple iPhone school of user experience) for it to feel natural. The main difference is how much the platform manages to disappear, more quickly than any device I've ever used. That's one of the things I love so much about OS X: it tries to get and stay out of your way.

Using a well designed iPad app (and there are already some pretty stunning ones), you quickly forget all about the hardware/software combination that is the life support for the app. The application just seems to work.

Canon Cat

In The Humane Interface, Jef Raskin (one of the early Macintosh developers and a well respected researcher in human-computer interaction) wrote about human computer interaction at a pretty abstract level. He designed and sold a computer called the Canon Cat which implemented some of his user interface ideas. One of the most shocking things that Raskin pointed out is that computer users don't want file systems, they just want to work on stuff. The Canon Cat had no recognizable file system: you typed documents and then searched to find previous ones. The iPhone/iPad also have no visible file system: every application "owns" their own data. This causes a few headaches for applications that need to sync their data or share files, but applications (like DropBox) fill that void nicely. I'd rather a few applications figure this out for themselves rather than punish every user with having to understand the nuances & headaches from dealing with what really should be low-level abstractions. How many family members have you had to walk through downloading a family photo and then helping them figure out where it ended up on their computer?

For those who doubt what a paradigm shift this is (and how far away even close seeming competitors are), consider that at the time I wrote this, 2 of the top selling applications on the Android store don't make sense on the iPad: a task killer & a file system browser. Despite the cosmetic similarities between the iPad and competitors, the differences go much deeper.

Death of the Mouse

The iPad represents the death of the mouse. You don't need one, don't miss one, and it would be a huge leap backwards to try to use one. Your finger does what needs to be done, and it's scary easy. The only real exception to this is stylus-type usage. The iPad is a lackluster real-time note taking device for handwritten notes. However, the built-in keyboard works better than I expected.

The Good

As you can probably guess, I like a lot of stuff about the iPad.

Mechanics

My general computing time (time spent on notebook, iPad, & iPhone (minus calls)) has gone slightly up since getting the iPad. Most of the displaced time has come from the iPhone. If you look at 100% of my ipad usage, I estimate that it comes from 80% less time on the phone and 20% less time on my computer. When I first got it, I had the normal hedonic glow I get from new cool toys, and I looked for excuses to use it. That quickly went away, and now i find myself using it for very specific tasks. Case in point: I realized I wanted to add this section while standing in line to get on a plane; I'm typing this in my seat waiting for the rest of the passengers to board. Not enough time to get the entire laptop out, but way more than I would want to type on my phone. Once you've been using the iPad, some of the applications on the iPhone feel really claustrophobic. Some applications (and games) still work best on the phone, but there is certainly the case that some (most?) work better on the more capable hardware and form factor.

Killer Uses

Watching movies rocks on the iPad. It has 1024x768 resolution (which was the standard resolution for my laptop for years) which is beautiful. Watching content at the gym is absolutely transformative. The Google map application quickly shows that this is the perfect form factor and, more importantly, interaction model. The way you pinch and zoom to navigate around the map feels right, along with the gradual exposition of details as you do so.

Listening to music with the lyrics available is another killer feature for me (I listen to a fair amount of music — progressive rock & opera — where the lyrics really matter). If you associate the lyrics to a song as part of the meta-data in iTunes, the iPad has a mode that shows you the lyrics to the song that's playing. You've been able to do this on iPods & the iPhone for a while, but this form factor makes all the difference.

The iPad is definitely a "lean back" device, rather than a "lean forward" device. The interaction model for a laptop is well established and doesn't have a lot of options because of the form factor. Whether at a desk or an airplane, you pretty much use it the same way. The iPad, on the other hand, has lots of different interaction modes. I've seen a lot written about "habit spaces" and interaction models — the iPad makes you realize how true that is, and provides a blank slate for creating some new habit spaces & interaction models.

Using a mind mapping tool on the iPad makes me never want to go back to using a notebook for this activity. The mind mapping tools aren't as powerful yet, but the interaction is exactly right. I find I use my iPad a lot for brainstorming away from my computer, which is where I would like for it to happen because of habit spaces. And OmniGraffle for the iPad makes you rethink how drawing tools should work.

One must-have accessory is the Apple case for the iPad. It is a marvel of engineering in its own right, and it makes it easy to find the right interaction mode for what you're doing. Having a case that allows you to put it into various physical permutations makes it easier to get immersed.

The iPad is the ultimate airplane accessory: movies, books, games, and interacting with the outside world on planes with wi-fi. I have now partitioned my travel life into 2 eras: pre-iPad & post-iPad, and you can guess which is better.

As you've probably guessed, this entire entry was researched, organized, and written on the iPad, and it was a pretty good experience, much better than I thought it would be. I can anticipate doing more of this type of writing on the iPad.

The Bad

I have very little to dislike so far. It really does need rudimentary background processing just to allow stuff like Skype + X. The proposed changes coming in the 4th release of iOS should solve most of those problems. Doing real work on the iPad feels a little like being back in the DOS days. I had my notes for this blog entry in a mind map & had to switch back and forth. However, the pain was minor because the applications "start up" so fast (in quotes because that seems like kind of a quaint notion on the iPad: applications don't really have life cycles).

The Ugly

Nothing about the device is ugly. The only ugly thing in the neighborhood are Apple's sometimes overly controlling ways. But you have to realize that the future of applications on these devices fall into 2 categories: curated native applications from the AppStore and wide open, standards-based web applications, delivered through the browser. By maintaining control on the native applications, they remove the need for things like anti-virus software. They want to closely guard those applications all the way down to the look and a feel. I agree that if they allow cross- compiled applications, it dilutes their control. But that control makes a difference.

Before the iPhone, I was a die hard Palm (and Treo) user, which both offered an application development platform. Because there was no curator, 98% of Palm applications were abysmal, to the point that I stopped adding new applications. The Apple AppStore largely fixes that.

Android is going to suffer the same fate if they aren't careful. The interesting difference between the Palm & Android eras is the strength of social networks, especially user ratings. The largely unanswered question: will social networks be enough to all the cream of the Android crop to rise to the top, overcoming the Palm problem.

I won't get in a huff at Apple for controlling and curating native applications as long as they don't try to cripple the browser. As long as I can write whatever application I want using open standards and have it work correctly, I'm OK with the advantages and disadvantages of curated applications.

"I want to live there!"

I have a friend that every time he sees something new and futuristic, he says "I want to live there". Using the iPad feels like tiptoeing in to the future. I definitely want to live there.

I'm convinced that the iPad is the first iteration of the next major computing platform. PC's will become work & power user tools, but everyone will use iPad-like things for many tasks. This is the first incarnation - can you imagine what these things will look like in 5 years?

The iPad does for video what the Sony Walkman did for music. I can easily envision a near future where the family TV is only used on special occasions; the whole family sits around with their fifth generation iPad watching highly personalized content.

I don't think you can really appreciate the impact of the iPad until you've used one a bit. Thomas Watson famously said in 1943 that the world-wide market for computers was about 5 computers. He didn't understand the transformative effect that pervasive personal computing could effect. We're at the threshold of a new era of computing, and it's pretty cool. Ignore it at your peril!

Mouseless Browsing

2010-05-21T11:03:00.002-05:00

Once you write a book, you become really immersed in the subject matter. After it's off to the publisher, you can't turn off your interest in the subject. Consequently, after The Productive Programmer came out, I continue to find new ways to make myself more productive. One of my recent tendencies is mouseless browsing.

I have a love/hate affair with Firefox. I love the keyboard affordances it provides, especially the slash ("/") and apostrophe ("'") shortcuts. When looking at a web page, the slash starts an incremental find for text within the page. The apostrophe does something similar, but it restricts the matches to URLs only. How many times do you go to a web site and you know the name of the link you want already? For example, if I need to go to the ThoughtWorks web site to get the address of the London location (this happened earlier today), I know (or can guess) that there is a "Contact" link on the home page, which takes me to a list of offices. In my new mouseless browsing mode, I go to the home page thoughtworks.com, hit the apostrophe and start typing "contact", hit enter and now I'm on the contact page. From there, I can hit the slash key and start typing "London". I've found my address and never taken my fingers off the home row. This added to the spacebar to scroll down and shift-spacebar to scroll up and you can get a lot done in a browser without a mouse.

I maintain a love/hate relationship because one of the cool things about Firefox is all the plug-ins available. Conversely, one of the things I hate about Firefox are all the plug-ins! I tend to find useful plug-ins and add them, which adds to the weight (and start up time) for the whole browser. Recently, I stumbled across Camino, which uses the same rendering engine as Firefox, which means that my 2 favorite keyboard shortcuts work. Camino is very lightweight (if "feels" lighter than Safari) and it supports my browsing habits. This is going to sound odd, but one of the critical things that it supports is the ability to type a partial URL in the address bar (which it will auto-complete) and hit CTRL-N to move the cursor down to the first (or subsequent) matches. This is a big deal for me because the Emacs key bindings are deeply ingrained in my fingers (and most of OS X, as it turns out), but Firefox doesn't allow this. Firefox has apparently overwritten the CTRL-N key to do nothing (overriding the operating system). While this sounds minor, it bites me every time. Fortunately, Camino adheres to the Apple standard, allowing me to have my cake (having CTRL-N move down one line, as it was Meant To Be) and keyboard-driven browsing.

If you really want to go far down this path, there is the Conkeror browser. It's "About:"

Conkeror is a keyboard-oriented, highly-customizable, highly-extensible web browser based on Mozilla XULRunner, written mainly in JavaScript, and inspired by exceptional software such as Emacs and vi. Conkeror features a sophisticated keyboard system, allowing users to run commands and interact with content in powerful and novel ways. It is self-documenting, featuring a powerful interactive help system.

I have played with Conkeror and it has strong promise, but it's not quite mature enough for me to switch to daily use.

And if you are a Vim junkie, you can use the Firefox plugin called vimperator, which converts Firefix to a purely vi interface. Not for the faint of heart: if you don't know how to quit Vim, you're going to have a tough time with vimperator. Hard-core Vim-mers swear by this, but I'm too far gone down the Emacs route now to re-map the genes in my fingertips.

Mouseless browsing takes acclimatization, but once you become accustomed to it, you'll start finding it annoying to reach for a mouse (or even for the arrow keys -- not the home row!). This is why I have no interest in Chrome for now because it doesn't support my normal mode of browsing.

Tiffany Lentz: A New Regular on the No Fluff, Just Stuff Tour

2010-04-14T11:44:00.001-05:00

It is with great pleasure that I welcome one of my ThoughtWorks colleagues, Tiffany Lentz, to the No Fluff, Just Stuff tour this weekend in Tampa. She did the Seattle show last year to great feedback, and now she's joining the tour as a semi-regular speaker.

Tiffany has been with ThoughtWorks since late 2004 as a project manager and agile coach. She embodies what makes ThoughtWorks project managers so good: enthusiasm, experience, expertise on how to build software, and infectious enthusiasm. She's one of the project managers that I would work with on any project, no matter how bad it looks at the outset because I know that she'll find ways to make it better, usually profoundly better.

I've been leaning on Tiffany for a couple of years now to come speak on the No Fluff, Just Stuff tour to share some of her agile expertise, and she finally knuckled under and decided to join the No Fluff, Just Stuff speaker's "boy's club". I don't think it's a coincidence that 2 of the rare female speakers on the No Fluff, Just Stuff in recent times have been ThoughtWorkers: Tiffany and our CTO, Rebecca Parsons. ThoughtWorks can be a bit of a fraternal atmosphere as well (especially amongst developers which, despite concerted efforts, still remain largely male), which means that Tiffany and other ThoughtWorks females learn to tolerate too many male geeks being around, like the speakers at No Fluff, Just Stuff.

Tiffany is going to be talking about Agile practices this weekend in Tampa. Her talks include The Agile Mindset: Applying Agile in Non-Technical Areas of an Organization, Iteration Management: What's in Your Toolkit, and Agile Project and Management Metrics: Measuring Success Downward and Upward. If you're in Tampa this weekend (or at a future tour stop), do yourself a favor and go see Tiffany speak.

Empowering Sinookas using Social Networks to Maintain a Durass

2009-12-22T12:41:00.002-05:00

One of the recommendations I frequently give at conferences when asked about "What books are you reading" is to get out of the purely technical realm often so that you can communicate more effectively with the other humanoids. One of the common recommendations is to read all of the books by Kurt Vonnegut. One of his books I recently re-read (for probably the 15th time) is Cat's Cradle. In Cat's Cradle, Vonnegut defines a new religion called Bokononism (one of the first lines of the novel states that if you have a hard time believing that a perfectly useful religion can't be based entirely on lies, you won't like the book). Bokononism defines a bunch of new terms, which relates to the point of this blog.

First, some definitions from Bokononism:

karass: a group of people who, often unknowingly, are working together to do God's will. The people can be thought of as fingers in a Cat's Cradle.

duprass: a karass of only two people. The typical example is a loving couple who work together for a great purpose.

sinookas: The intertwining "tendrils" of people's lives.

wampeter: the central point of a karass

OK, so what does this have to do with anything useful? I travel a lot, even for a ThoughtWorker (a little over 200K miles this year). Of course, my wife hates the amount that I travel, but it's an occupational hazard. One of the things that makes us miss each other are the little unimportant side conversations we have when we are together: little meaningless observations, inside jokes, just the kind of things that people in a duprass do all the time. So I built a sinookas using Twitter.

I created a new GMail account for myself and one for my wife. Using each of those GMail accounts, I created a new Twitter account with protected updates for each of us, and we only subscribe to each other's Twitter stream. All the good Twitter clients make it easy to change accounts, so I have used this to create a private back channel for ongoing duprass style conversations (in other words, a sinookas). This isn't the wampeter of our duprass, but it does make the sinookas stronger. It's been great, and it's something that I recommend all traveling road warriors set up.

Now, my wife & I can have an ongoing private conversation about stuff that wouldn't make sense (or would be too politically incorrect) on a public feed. That allows us to miss each other less. Who says that you can't have a perfectly useful social network with just 2 people?

Productivity Pron

2009-11-04T11:36:00.000-05:00

One of my former coworkers & I used to spend hours talking about how to set up the best individualized personal information manager. We used to call those conversations productivity porn, not realizing that someone would come along an formalize that term, albeit slightly skewed, as Productivity Pr0n. Finding a good system that doesn't get in your way yet allows you to organize all the things going on in your life (both personal and professional) is surprisingly difficult, given the number of tools that purport to do just this. At the time we were having these discussions (late 1990's), the best thing going was Franklin Covey's Ascend (a desktop application for Windows) and the Palm Treo. Ascend replaced some of the anemic default applications on the Treo (like the laughable ToDo application) with their own versions, and it worked really well. The death knell for me with Ascend was its poor quality. It was written as a desktop application that used an Access database for its back end, and it was a bit fragile. About once a year, it would spontaneously corrupt the database, which required cracking it open with Access to fix the mess it had gotten itself into. Seeing the broken and corrupted records and the general ghetto-ness of the database Ascend supposedly owned entirely didn't give me confidence. I still haven't found as good as integrated system today, but I have cobbled together a nice workable system for myself, consisting of 5 moving parts.

Calendar

This piece to me is the easiest slot to fill. Maybe I'm just not discriminating, but almost any calendar application works fine for me. As long as I can add appointments with all the standard stuff (reminders, time zones, etc.), I'm pretty happy. The biggest headache with calendars is keeping them in sync. Back in the bad old days of Lotus Notes at ThoughtWorks, I basically ignored the corporate calendar, keeping all my stuff in Google Calendar instead and giving people who cared an HTML view into my work calendar. Google calendar is quite nice, including good synchronization / replication with iCal. Most of my interaction with Google calendar was through the web interface, so much that I created a fluid application that had only my calendar. One of the slick tricks you can do with fluid applications is make all the chrome disappear, giving me a full-screen calendar bound to one of my desktops that looked like the wallpaper for that desktop, which was nice because you get the biggest possible calendar. I also liked the 4 views afforded by Google calendar: 1 day, 1 week, 1 month, and next 4 days.

Since ThoughtWorks moved our infrastructure to Google applications, I just exported my old work calendar and sucked it into the new ThoughtWorks Google calendar. My itineraries, my wife's schedule, etc. I subscribe to (and share subscriptions to interesting events with her). We each "own" our own calendar and cross-subscribe to get shared events. Using sites like TripIt makes keeping travel under control and subscribable. Going forward, I want all calendar stuff delivered as iCal feeds.

For synchronization, I'm using iCal as the integration point. I still have a fluid application that now points to my ThoughtWorks calendar, but I'm using iCal as the main calendar. Of course, iCal synchronizes nicely with the iPhone. Before moving back to iCal, I was using CalenGoo on my iPhone, which is a slick iPhone interface directly to Google calendar. It doesn't really provide off-line access but does cache the previous results so you can see your calendar even if you can't get to it online. The native iPhone calendar application handles that for me now.

ToDo / Task List

If the calendar is the easiest, this is by far the hardest slot to fill. Virtually all of the To Do / Task List applications I've used are seriously deficient in one way or another. Ascend replaced the Palm ToDo application (which was laughably bad) with one it called Task List, which was quite good. One of the killer features I need is a start date in additional to a due date (they all do due dates, but most don't handle start date properly). I have a fair number of tasks that I don't need to see right now, but I don't need to find out about them the day they're due either. I need a system that allows me to express "this thing is due on 11/5, but start pestering me about it on 10/30". I also want a tag-based system using contexts, one of the really nice refinements to come from the Getting Things Done cult, rather than a hierarchy of folders.

My research in this area eventually led me to OmniFocus. I say "eventually" because I recently went through this category of application again. I started with OmniFocus but found it too complex for my day to day usage, which led me to Things. I like Things because it is so radically simple, but that became a bottleneck for me because of the way I like to attack projects. That in turn led me back around to OmniFocus and some concentrated learning about how it wants to work. It's heritage is OmniOutliner, and you can still see that lineage, which adds some complexity to some parts. Because OmniFocus has lots of ways to get information into it, I kept misplacing stuff. The thing that took OmniFocus from "nice but tolerable" to "can't live without it" is the custom perspectives. OmniFocus allows you to save customized views, including filters, columns, etc. I created a bunch of custom perspectives that show me exactly what I need ("what things are coming due within the next week", "what needs to be done next on this project", "I have 10 minutes at home -- is there anything that can be done here and now?") and assigned those perspectives to hot-keys using the standard Mac feature of assigning keys to menu items (each perspective shows up as a menu item, making this possible). Now, I never use the built-in views, I always use my custom perspective depending on the information I need right now. Since doing that, OmniFocus has worked fantastically. It allows me to organize my days and weeks, just shows me what I need right now, and I'm confident when I add something to it that it'll appear at the right place and time. Learning to use OmniFocus right was the key, and now that I have I think I have the best task list stuff that I've ever had (beating out Ascend for this title is no small feat).

Of course, OmniFocus syncs with the iPhone (and has a terrific iPhone application) so that I can keep all my To Do stuff with me at all times.

Recurrence

OmniFocus is great for tasks that have firm due dates and works for recurring tasks as well (including some nice flexibility around "schedule the next one of these 5 weeks after the completion of this occurrence", which is great for things like haircuts). However, I have a few but important categories of things where I want to define rules like "I want to post to my blog every 9 days or so", which could be rewritten as "remind me after 7 days that I need to post a blog entry, and start yelling after 11 days if it isn't done". I use a highly specialized tool for this called Sciral Consistency. That's all this tool does: allows you to set up ranges for things that need to be done and remind you.

I could almost replicate this using OmniFocus features, but I already had Sciral and I like the minimal display & single-mindedness of the tool. This doesn't synchronize anywhere, but I always consume this information at my computer anyway.

Random Notes

The combination of calendar and OmniFocus handles all the structured stuff -- what about unstructured notes? I have two mechanisms for that: Evernote and Moleskine.

Evernote

Evernote is a desktop, web, and iPhone application that allows you to capture notes (organized into notebooks) for whatever information you want to keep and search. A few killer features for me:

Automatic synchronization always everywhere. Every time you capture something with Evernote, it automatically synchronizes across all views.

OCR for white board text. I tend to draw on white boards a lot, and if you capture the drawing with Evernote's picture note, it will allow you to do text searches in the web and desktop client for words in the white board drawing. It's not perfect but surprisingly good at this.

Automatic forwarding address. Evernote sets up an email address for you; anything you forward to that address becomes a notebook entry. This is nice because it allows you to get stuff out of your email client. Evernote has much better searching capabilities than most email clients, and having the forwarding address means you can get searchable emails into Evernote very easily. This is particularly nice for those who use their email inbox as the world's worst filing cabinet; get that stuff out of your email client and into something where it can be useful.

Moleskine

The only bad thing about an entirely electronic PIM: there are still times when you cannot use it (like when the plane it taxiing). This may not seem like a big deal, but I find that I have lots of capturable ideas at exactly the times when I can't capture them. Thus, my other permanent GTD accessory is a soft-sided Moleskine book along with a Fisher space pen. I capture interesting ideas as soon as I have them (because ideas, especially those from the right brain, are fleeting). Once I get back to my computer, I transcribe the Moleskine notes into the rest of my system. At any given time, I usually have a page or so of new stuff in the Moleskine. I could get by with a few index cards but I've been carrying the Moleskine for a while and I'm used to it.

Tying It Together

My PIM lives between 4 different applications and a notebook with no real built-in integration between them. I always use them as a unit. For example, I have all 4 applications bound to the same desktop in Mac OS X, and those are the only things bound to that desktop. That allows me to always leave them in the same window state and position. Anytime I switch to one of the PIM applications, it goes to the appropriate desktop. I've also used Automator to create a PIM application that performs "Launch Application" for each of the 4 that make up my PIM. I no longer think about these applications as separate things.

PIM as Life Support for Focus

Obviously, this system is highly customized to me and won't work without changes for anyone else. I think that it is every knowledge worker's responsibility to find a system that allows them to get to and stay in flow as much as possible. Any tools that you use should make it easier to get to flow, not harder. I find that I tend to work best in 2 hour chunks (which I'm calling work blocks), which is similar to the very popular Pomodoro technique. One of the custom views in OmniFocus allows me to review projects that have pending work blocks so that I can find out what I need to work on, then immerse myself in that problem for a contiguous chunk of time. Whatever system you find, make sure that it supports how you want to work. Don't change your effective work habits to conform to some tool's vision of what your day should look like.

Twitter Matters: The Meme Abiogenesis of the Internet

2009-10-07T09:13:00.000-05:00

This is part three in an exploration of why Twitter makes sense, highlighting its use as a legitimate tool for connections and idea generation. The first article is under Twitter Matters: Keeping Up with Weak Social Links and the second is under Twitter Matters: Conversations vs. Monologues for those who want to catch up.

Abiogenesis, the study of how a primordial soup of chemicals eventually lead to amino acids and life, is an area of fascinating study by biologists. This spontaneous generation of life happened here a long time ago, and its study obviously interests those investigating life on other planets because this primordial soup seems to be the first prerequisite for life as we know it.

You can think of the Internet as a free-form gathering place for memes, an element of a culture or system of behavior that may be considered to be passed on from one individual to another by non-genetic means. Examples of memes include hit songs, water-cooler conversations about hit TV shows, and things like communism. If you are in the idea business (meaning that you are always looking for new sources of ideas and how to apply them to a broad subject like software development), you are always on the lookout for primordial meme pools. Twitter meets that goal admirably. As I mentioned in the first installment, weak social links are your best source for "outside the box" ideas. That makes Twitter a great place to harvest and generate new ideas. New ideas frequently start from seeds of an idea that are nourished into full-formed thoughts. Twitter now only delivers these seeds to your door, you can use them as an incubator for your own seeds.

Here's an example. One of my recent blog entries was called the Suck - Rock Dichotomy. That particular turn of phrase came from a quick one-off Twitter entry where I was responding to a Tweet from someone that combined rock and suck. I mentioned that the entire argument was really part of the pervasive suck/rock dichotomy in the software world. That worked nicely in a 140 character Twitter post, and it was modestly re-tweeted. But it started more serious thinking on why that phenomena exists, which further lead me to an entire blog post (i.e., essay) on the subject. The turn of phrase came from me, but in response to some other stimuli. Would I have ended up writing a blog post on that subject if it hadn't come up in a virtual conversation? Probably eventually, but having a conversational medium close by encouraged the original Tweet, which lead to more fully formed thoughts about the subject.

Finding new sources of in-context ideas is a gold mine because you can never tell what fruit those idea seedlings will bear. Yes, 99% of Twitter is mindless trivia, but discovering or creating a new idea that you wouldn't have had otherwise? Priceless. People complain that most of Twitter is drivel, and I won't dispute that against overwhelming evidence, but the remaining usefulness is an artifact of the volume of memes present. Here's an analogy. Numbers vary, but some sources suggest that up to 95% of the human genome is "junk DNA", DNA that isn't used (or at least its use hasn't been determined). That's how nature tries out new ideas, and the really good ones survive. Most of Twitter is junk, but good ideas do lurk in these murky meme pools.

Twitter has evolved to fill a niche that didn't exist before. Just like any social environment, users have to figure out a way that it can provide value. I've certainly found that for me. The combination of keeping up with my weak social links, having terse conversations vs. email monologues, the enforced constraint to keep ideas atomic, and the new medium of ideas forms a completely unanticipated but welcome enhancement to the way I work. Rather than cast stones at new technologies like social networks, ask yourself why people find it useful and how can it be useful to you. The answer may be "no", but you need to understand why it matters before dismissing it.

Twitter Matters: Conversations vs. Monologues

2009-09-29T12:04:00.002-05:00

This is part two in an exploration of why Twitter makes sense, highlighting its use as a legitimate tool for connections and idea generation. The first article appears as Twitter Matters: Keeping Up with Weak Social Links.

The 140 character limit is perhaps the most distinctive characteristics of Twitter. Some of my Twitter friends have commented that conversations on Twitter tend to be more civil: you just can't cram much message and bile into a 140-character message. This has happened to me: carrying on a debate on Twitter is an interesting exercise in conciseness. Tight constraint is a forcing function on creativity: sensibility, lucidity, and articularity in just 140 characters is tough. You would think that all discussions on Twitter are either about trivial subjects (so that you can fit it into the built-in limit) or quickly degrade into multi-part messages. While the latter happens sometimes, it is rare in my experience, and the former doesn't occur as much as you might think.

An example is in order. I recently posted a message in response to Jim Weirich that I thought that cyclomatic complexity wasn't as useful a metric in Ruby because so much of the things that normally require loops and branches are so handily encapsulated in powerful libraries. Thus, this effect causes cyclomatic complexity numbers to be lower when comparing apples-to-apples code in Java & Ruby. Jim correctly pointed out that that does in fact make the Ruby code simpler, and therefore cyclomatic complexity is measuring exactly what it is supposed to measure. During this same discussion, Glenn Vanderburg weighed in on a related subject, and then so did Ola Bini. The conversation quickly turned to the Sapir-Whorf Hypothesis and how viable it is for spoken languages (not much) and computer languages (much more so). Along they way, I learned the distinction between the strong and weak versions of Sapir-Whorf. All this took place over about 20 minutes, 140 characters at a time. Yet at the end, I knew a lot more than when I started. The combination of (shortened) links to external sources and brief forays kept the conversation focused, covering just a few topics and exploring the implications between them.

How would the conversation work without Twitter? It could only work if all the interested parties (myself, Jim, Glenn, and Ola) were somehow on the same email mailing list or happened to be at the same place at the same time. While our location does coincide occasionally, it's rare (we're based in Atlanta (sometimes), Cincinnati, Dallas, and Stockholm). Even so, the topic would have to come up in conversation. If we were on the same mailing list, the conversation would proceed differently. Because there is no character limit on email (I'll let you immerse yourself in the fantasy of a limitimg function on email for just a second), it's no longer a conversation, it's a series of monologues.

A tricky balance exists between constraint and creativity. Obviously you can cram more information and context into a sonnet than a Haiku (I explored this idea in a blog series about the expressiveness of the Ruby language back in 2007). 140 characters seems to be a bit of a sweet spot: enough to convey some thought but not enough to go overboard. Composing a good Twitter update is different from composing an entire blog but they aren't as far apart as you might think. I certainly have noticed that the people who both Twitter and blog have cut down on the number of blog entries they write. I'm certainly that way. It used to be that I would blog for 2 types of messages: short announcement type blogs ("I'm speaking at Random City Users Group next week") and essays. Now, all the short announcements happen on Twitter, leaving my blog for more formal essays. I like this distinction because I find that the blogs I read tend to be more substantive.

There is no question that most of what comes through Twitter aren't deep thoughts (many think that Twitter is just for food and travel). I find that people who only post obvious messages, too much information, or too much that I either don't care about or I find offensive don't stay on my list of people I follow long. There is at least one prominent technologist who mixes his interesting posts with right-wing bile, and I dropped him like a hot potato because I don't need a subscription to a channel for misinformed dogma. Managing your user list becomes important in Twitter so that you filter out stuff you don't want or need.

Twitter creates a new communication stream for those who contribute and consume Tweets (conversations vs. monologues). By creating a new specifically constrained communication channel, it moves conversations that used to occupy other spaces to a more appropriate space. This combination of a new conversational outlet between people with who I maintain weak links and the built-in constraints mean that I have a new source of ideas (both raw ideas and refinements of my ideas) to keep my brain percolating. In the next post, I explore the idea that Twitter can be a form of meme generator.

Twitter Matters: Keeping Up with Weak Social Links

2009-09-17T05:08:00.003-05:00

Lots of people just Don't Get(tm) social networking sites like FaceBook, MySpace, and especially Twitter. On the face of it, Twitter doesn't seem to make much sense: 140 character updates. But those of us who use Twitter a lot (I'm @neal4d, BTW) know that it's much more than that. Twitter engenders so much puzzlement because it's so restrictive, but the restriction is the genius of Twitter.

In this and the next two blog entries, I'm going to explore why Twitter is a Good Thing(tm) and some surprising ways it can insinuate itself into a useful workstream. The first of these observations is around links.

Andrew McAfee of Harvard has done a lot of research on how social networking intersects with the enterprise (soon to be captured in a book I can't wait to read, Enterprise 2.0). I saw him talk recently about why social networking is a valuable resource left barren by most companies. He defines 3 kinds of social links: strong, weak, and potential, shown in a bulls-eye layout:

Your strong links are the people you see regularly, either at the office or during the normal course of your life. There's a good chance you know what these people had for lunch, or at least one of their meals in the last week. The next layer represents your weak links. These are people you see intermittently (perhaps once a year). They are your friends that you don't get to see on a regular basis (because of geography, for example). A good example for me is my friend Hadi Hariri, who lives in Malaga, Spain. He & I see each other perhaps once a year (generally at conferences) and always have good fun & conversation. It's this group that social networking sites support. This is a valuable link because you are more likely to get novel ideas from this group than from your strong group. Before social networks, how did you keep up with your weak links? The Christmas Letter, summarizing a year's events? You are wasting an important link if you can't reach out to your weak links sometimes. You see your strong group all the time, so they hold few surprises. However, your larger and more diverse weak links provide novelty. The potential links are those who you'll form weak & strong links with, but you haven't met them yet. You're also more likely to be introduced to a potential links through your weak links.

Twitter provides a strong connectivity to your weak link. Here's an example of how weak links can lead down interesting paths. I met someone at the erubycon conference last year who's a well known figure in the Rails world and subsequently started follow his Twitter feed. He had very recently gone vegan for health reasons, and he tweeted a reference to an astounding book called The China Study. I read this book (and several other referenced in it) and have since been strictly vegetarian, at least for the time being. It's worth reading: it lays out the case against animal protein in your diet, and backs up the claims with real science. It's a profound book, enough to convince me to change my eating habits. I don't know if I'll stay this way forever, but I've been there for about 6 weeks and it has been quite pleasant. He was very much a weak link; I would have a hard time spotting him in a room. Yet we share enough context in the Ruby community for me to use him as a source of ideas, which sometimes lead to interesting places. In this case, I wouldn't currently be vegetarian if it wasn't for Twitter.

Finding a good mechanism for maintaining weak links and finding (and exploring) potential links allows you to work smarter because you have a broader arena for ideation. The combination of links, constraint, and meme ooze make Twitter very useful to me. I explore these other two aspects in the next two installments.

The 2009 Edition of the Rich Web Experience: Adding Spice to Your Applications

2009-09-09T03:47:00.000-05:00

Several years ago, I called an Ajax conference a condiment conference because most everyone there concerned themselves with technologies that augmented other technologies (for example, your base language is Java but you need JavaScript to make your applications suck less). Now, I think that user interaction, web design, the rise of Rich Internet Applications (when used suitably), and other user-facing issues have a deeper relationship to the underlying technologies. Thus, I'm calling this year's Rich Web Experience the spice for your underlying technology. Food is edible without condiments, but bland without spices. You can't avoid the browser as a platform; might as well embrace it in Orlando in December.

The Suck/Rock Dichotomy

2009-08-05T08:32:00.002-05:00

Lots of people are passionate about software development (much to the confusion and chagrin of our significant others), and that unfortunately leads to what I call the "Suck/Rock Dichotomy": everything in the software world either sucks or rocks, with nothing in between. While this may lead to interesting, endless debates (Emacs vs. vi, anyone?), ultimately it ill serves us as a community.

Having been in software communities for a while, I've seen several tribes form, thrive, then slowly die. It's a sad thing to watch a community die because many of the people in the community live in a state of denial: how could their wonderful thing (which rocks) disappear under this other hideous, inelegant, terrible thing (which sucks). I was part of the Clipper) community (which I joined at its height) and watched it die rather rapidly when Windows ate DOS. I was intimately part of the Delphi community which, while not dead yet, is rapidly approaching death. When a community fades, the fanaticism of the remaining members increases proportionally for every member they lose, until you are left with one person whose veins stick out on their forehead when they try to proselytize people to join their tribe, which rocks, and leave that other tribe, which sucks.

Why is this dichotomy so stark in the software development world? I suspect a couple of root causes. First, because it takes a non-trivial time investment for proficiency in software tribes, people fear that they have chosen poorly and thus wasted their time. Perhaps the degree in which something rocks is proportional to the time investment in learning that technology. Second, technologists and particularly developers stereotypically tend to socialize via tribal ritual. How many software development teams have you seen that are not too far removed from fraternities? Because software is fundamentally a communication game, I think that the fraternal nature of most projects makes it easier to write good software. But tribal ritual implies that one of the defining characteristics of your tribe is the denigration of other tribes (we rock, they suck). In fact, some tribes within software seem to define themselves in how loudly they can say that everything sucks, except of course their beautiful thing, which rocks.

Some communities try to purposefully pick fights with others just so they can thump their collective chests over how much they rock compared to how much the other guys suck. Of course, you get camps that are truly different in many, many ways (Emacs vs. vi, anyone?) But you also see this in communities that are quite similar; one of the most annoying characteristics of some communities is how much some a few of their members try to bait other communities that aren't interested in fighting.

The Suck/Rock Dichotomy hurts us because it obscures legitimate conversations about the real differences between things. Truly balanced comparisons are rare (for an outstanding example of a balanced, well considered, sober comparison of Prototype and JQuery, check out Glenn Vanderburg's post). I try to avoid this dichotomy (some would say with varying degrees of success). For example, for the past 2 years, I've done a Comparing Groovy & JRuby talk at JavaOne, and it's been mostly well received by members of both communities. Putting together such a talk or blog entry takes a lot of effort, though: you have to learn not just the surface area details of said technologies, but how to use it idiomatically as well, which takes time. I suspect that's why you don't see more nuanced comparisons: it's a lot easier to resort to either suck or rock.

Ultimately, we need informed debates about the relative merits of various choices. The Suck/Rock Dichotomy adds heat but not much light. Technologists marginalize our influence within organizations because the non-techies hear us endless debating stuff that sounds like arguments over how many angels can dance on the head of a pin. If we argue about seemingly trivial things like that, then why listen to us when we passionately argue about stuff that is immediately important, like technical debt or why we can't disprove The Mythical Man Month on this project. To summarize: the Suck/Rock Dichotomy sucks!

Productivity & Location Awareness

2009-07-15T15:48:00.001-05:00

The iPhone has retaught me the power of location awareness in user interfaces. I have lots of iPhone applications (about 90 at the current count, but, in my defense, some of those are saved bookmarks), and until the iPhone 3 update, touching the icon is the only way to invoke them. Because I have so many, I started organizing them on desktops based on usage (for example, I have a travel desktop, a food desktop, hyperlink desktop, etc). This became too arbitrary, so I recently just went alphabetical for all but the first desktop, which has a special hot key to get back to it, making it the perfect place for really oft-used applications.

The point is that I've rearranged my iPhone icons several times. It continues to surprise me how quickly I remember the desktop and location on the desktop of a given application. I very quickly learn where the applications I use all the time (TripIt, I'm looking at you) and can get there really fast. I find that even though Spotlight now works on the iPhone, I still generally go directly to the application via the icon.

While clearly launchers like Quicksilver, Spotlight, and Launchy work better for the huge numbers of applications you find traditional computers, the power of location awareness suggests several things for the builders of applications.

Don't move stuff around.

navigation controls are hyperlinks. But, because of add placement, they move around slightly, turning reading the groups a game of "Whack-a-Mole". I use either the NumberFox plugin or Firefox's incremental hyperlink search (the apostrophe hotkey) rather than chase the stupid hyperlinks with a mouse.

I hate applications that move menu options around based on usage. Consistency is important for usability. In fact, I use the Mac's the Smart Menu Search feature, which allows you to incrementally search for menu items without regard for their physical location, as my favorite menu affordance.

Context sensitivity makes it hard to leverage location awareness.

Context sensitivity for toolbar buttons makes it hard to definitively learn where something lives, which kind of dooms the ribbon user interface metaphor in modern versions of Office. While I understand the need for a rethought user interface metaphor for the huge number of features (perhaps that's the underlying problem?), having a context-sensitive set of toolbars means that, to become really effective, you have to memorize each combination of buttons and the corresponding locations. Not having used the ribbon much (I avoid Office applications pretty assiduously), I can't say whether you eventually build up the cognitive ability to utilize location awareness.

User interface designers should understand Fitt's Law

Pop quiz: what?s the biggest clickable target on your screen? It?s the one right under your cursor, which is why the right-mouse menu should have the most important things on it. The target right under your mouse is effectively infinitely large. Second question: what?s the next biggest target? The edges of the screen because you can accelerate as fast as possible to the edge and not overshoot it. This suggests that the really important stuff should reside on the edges of the screen. These observations come from Fitt's Law, which states that the ease of clicking on a target with the mouse is a combination of the distance you must navigate and the size of the target.

The designers of Mac OS X knew this law, which is why the menu bar resides at the top of the screen. When you use the mouse to click one of the menu items, you can ram the mouse pointer up against the top of the screen and you are where you want to be. Windows, on the other hand, has a title bar at the top of each window. Even if the window is maximized, you still must carefully find your target by accelerating to the top, and then use some precision mousing to hit the target. For right-handed users, the upper right corner is an easy mouse target. What's there on the Mac? Spotlight, the universal search utility. What's there on Windows? Nothing unless your application is full screen, and, if it is, it's the close button (which suggests the most important thing you can do to a Windows applications is close it).

There is a way to mitigate this for some Windows applications. The Microsoft Office suite has a Full Screen mode, which gets rid of the title bar and puts the menu right at the top, like Mac OS X. There is help for developers, too. Visual Studio features the same full-screen mode, as does IntelliJ for Java developers. If you are going to use the mouse, using your applications in full-screen mode makes it easier to hit the menus because it takes advantage of location awareness and consistency.

Regardless of the power of location awareness, for sophisticated computer users (like developers), location awareness doesn't scale. You should spend the time to learn the keyboard shortcuts for every possible thing you need to do. It takes longer, but it scales almost indefinitely. In fact, I turn toolbars and buttons off in IDEs and Emacs and take the time to learn how to get to what I need without reaching for the evil mouse. I'm curious to see how much I start using Spotlight on the iPhone as the number of applications I have keeps growing (which seems inevitable at this point).

Orlando JUG on Thursday June 25th

2009-06-23T23:58:00.000-05:00

If you are anywhere nearby, come see me at the Orlando JUG on June 25th, 2009. I'll be giving my newly revamped Real-World Refactoring talk. By revamped, I mean that I've added a bunch of examples of architecture smells and how to attack them. From the No Fluff, Just Stuff web site description of the talk:

Refactoring is a fine academic exercise in the perfect world, but we don't really live there. Even with the best intentions, projects build up technical debt and crufty bad things. This session covers refactoring in the real world, at both the atomic level (how to refactor towards composed method and the single level of abstraction principle) to larger project strategies for multi-day refactoring efforts. This talk provides practical strategies for real projects to effectively refactor your code.

This talk is part of a series of talks I'm doing this year on Emergent Design & Evolutionary Architecture, showing examples of how to use refactoring to fix architectural and design smells. I also cover refactoring databases and build files.

Come join us.

AML (Arbitrary Modeling Language)

2009-06-10T15:08:00.001-05:00

UML is a failure. It failed for several reasons. Mainly, it failed because it falls into the cracks between technical people (developers, architects) and non-technical people (business analysts, project managers, etc). UML is too technical for non-technical people, and not technical enough for technical people. By this, I mean that it isn't really technical enough to do serious work on design by techies. At the same time, it's obscure enough to be mostly incomprehensible to non-techies.

This wasn't the Three Amigos fault. They did quite impressive work on the meta-model aspect of UML. It was defeated by two forces. First, the fundamental problem lies with the amorphous nature of software itself. Coming up with a really expressive graphical notation is hard. Most developers know enough to draw boxes for classes and open-arrowheads for inheritance, but don't get much further into the UML specification because it gets quite convoluted (especially if you start looking at the later generations of UML, with Object Constraint Language and its ilk).

The second failure reason is the implicit assumption that you need (nay, must) design all the classes and interactions before you start writing code. Big Design Up Front is a failed technique in almost all software development. The only exceptions are systems that are truly life and death. One of the reasons for the outdatedness of the software on the space shuttle lies with the fact that they have very long iterations. In other words, they are willing to say "once this date passes, we will make no changes to the design of this system. Period." While most business software could make this statement, it ill serves the business. Business processes change like the weather, and you need software that can change just as readily. I don't come to this discussion as a dilettante: for a while, I worked for a company that was a Rational partner. We did the training, and we built software based on the Rational Unified Process. We even had some successes. But it didn't take long for us to realize that the upfront design didn't serve our clients because it hampered the kinds of changes required by their business.

Most developers I know use AML: Arbitrary Markup Language, usually consisting of boxes, circles, and lines. When a given developer writes on a whiteboard, they write in their own version of a diagramming language. It's a shame that we don't have an industry wide diagramming language that everyone feels compelled to use, but that's the reality in most places I've been for the last 5 years. But, having said that, I'm a fan of AML, because it cuts down on irrational artifact attachment: you have nothing except the last 5 minutes invested in the diagram, making it as transient as possible. Transient artifacts are good because you're willing to throw them away, preventing them from becoming a part of the documentation for your project once the actual code has migrated away from that initial stab at design. Out of date documentation is worse than none at all because it actively misleads

Mac Boot Mysteries

2009-05-26T08:36:00.001-05:00

This is long, digressive story about diagnosing a hardware problem on a Mac; if you dislike such stories, feel free to leave now.

About a week ago, my wife Candy complains to me that her Mac won't boot up. This is my hand-me-down Mac (we have a new policy in our house: Candy gets my hand-me-down computers, and I get her hand-me-down cameras), which means that it's about 2 years old, but it has a relatively new hard drive that I installed last November. A long time ago, I had set the startup option to always run in Verbose startup mode (on demand by holding COMMAND-V upon startup, or permanent by issuing the following command:

sudo nvram boot-args="-v"

Anyway, I could see from the startup porn that she was having a kernel panic with 2 likely suspects: the fan control daemon and something about Cisco VPN. Now, Candy doesn't have a Cisco VPN, but given that this was my hand-me-down machine, that explains why some of that stuff is there. Candy hadn't installed anything in the last week or so, leading me to think that one of these two was the culprit. She had been complaining that her machine was getting slower and slower, including things like window resizing, which had me puzzled. Perhaps a dying fan was causing the processor to overheat and thus slow down?

I tried safe boot (no joy), and at this point I suspect the fan. I'm certainly not afraid to crack open a Mac (with proper respect), but replacing a fan isn't high on my list of fun things to do, so we made an appointment at the Genius bar. To Candy's credit, she had a SuperDuper! backup that was just a couple of days old, so virtually everything was safe.

We went to the genius bar where the GenX slacker (this is a compliment) booted the Mac from an external drive. I hadn't tried this (even though I have several bootable drives laying around) because I was fixated on the fan problem. After booting it up, his suspicion now lies with the VPN stuff, and I reluctantly concur (especially after he ran some fan diagnostics). Now, though, the question remains: why did this problem suddenly occur? What was his (depressing) advice to fix this problem? Reinstall Leopard and all your applications. What?!? Is this a freakin' Windows machine? I couldn't believe that was real Genius advice. I've never yet had to do a ground-up reinstall of everything, but if that's the only way...hmmmm. He was very knowledgeable, and obviously he doesn't tread in the realm of VPN stuff. He also correctly pointed out that a bad fan shouldn't cause slowness: redrawing windows is mostly handled by the GPU on the Mac. The slowness was as far as I can tell a red herring.

When I got home, the first thing I did was boot Mac OS X from an external drive and get a real SuperDuper! snapshot, getting the real current snapshot. Once I have that, I can play. Candy has already agreed to the pain and degradation of reinstalling everything, but I have to think there's a better way. Then, I had a brain storm: I took the SuperDuper! snapshot I just made and booted the machine from the external drive. Success! That suggests that some part of the internal hard drive that houses the VPN stuff has somehow gotten corrupted, but still allows it to boot using the same image from an external drive. Because I have the SuperDuper! safety net, I decided on an experiment. I reformatted the internal hard drive and ran Drive Genius on it to scan for bad sectors. Nothing of note came from that, but then I overlaid my most recent SuperDuper! snapshot back onto the internal drive.

Success! The internal drive now boots, and everything appears back to normal. I'm guessing that my bad sector theory was correct.

Lessons:

Don't reinstall everything! My record is still clean on that account: I have never had to do that on a Mac yet (and it was a once-a-year chore on Windows because of bit rot).

Always have good backups. This would have been a tragedy rather than a comedy if Candy hadn't been using SuperDuper!. It has yet to let me down, and it has saved my bacon on several occasions.

I immediately latched onto the fan because it seemed to support other observed phenomena. I should have booted it myself from an external drive and run Drive Genius, but I thought I had it figured out.

Stop and think. It was a good thing that we had dinner plans with a neighbor when we got back from the genius bar. It was over dinner that I had the idea of just overlaying the snapshot again. If I had started on it as soon as we got back, I would have been creating a lot of movement without a lot of forward progress. Sitting and thinking about it opened my mind to alternative options.

SuperDuper! rocks. I can't imagine life without it.

RailsWayCon

2009-05-11T16:32:00.001-05:00

The economic downturn has affected conference attendance. At the conferences where I've spoken in the US, attendance seems to be down 20-30% from last year. However, it doesn't seem to have been as bad at European conferences (of course, it may just be the conferences where I'm speaking), where attendance is down only a little. It was surprising then that O'Reilly decided not to conduct RailsConf Europe this year.

However, someone has stepped in to fill the gap: RailsWayCon is happening in Berlin from May 25-27. They have gathered speakers from far and wide in what looks a rockin' good conference. If you're anywhere in the neighborhood and looking for a Ruby and Rails conference, this is the one for 2009.

Confessions of a Reformed Titilator

2009-05-01T11:21:00.001-05:00

The Rails community has a real brouhaha on its hands, but it's a red herring that it happens to be Ruby and Rails because it's a pervasive problem in scientific and engineering fields of all kinds. It seems that a presentation at the GoGaRuCo Ruby conference (Golden Gate Ruby Conference) included a heaping pile of really racy, semi-pornographic imagery. The presenters hand-waved it away by telling the attendees that the images existed to keep everyone's interest in their presentation. And, fortunately, some people called their bluff.

Studies exist that show imagery that bores into people's basest parts (sex, violence, humor) is the easiest way to keep people interested in an otherwise boring topic. Lots of presenters use this technique to engage and keep attendees attention. I know because I've used it myself. And it's really our most slovenly kind of laziness as presenters at work. Let me explain how I've come around to this conclusion.

At RailsConf last year, Joel Spolsky did one of the morning keynotes. As his first slide, he showed a glamor shot of Angelina Jolie and said (I'm paraphrasing) "I always show this as my first slide because I always get better evaluation scores on my keynotes when I do." His next slide showed Brad Pitt, with his shirt open, and Joel added "And, just to be demographically fair, I show this one next." Joel was plugging into 2 techniques for capturing attention: sex and humor. And it works on some level. The crowd (mostly) loved it. In his keynote, it was basically gratuitous: he never used it for anything other than pure pandering. But I'm always on the prowl for effective presentation tricks, so I borrowed Joel's trick, but with a twist.

In my Ceremony & Essence keynote, which I gave at a hand-full of Ruby events last year, I had a similar picture of Angelina and Brad at the start, using it to get a laugh right out of the gate. In a keynote, if you can get people laughing early, they loosen up more and are more likely to laugh more and emote more back to the presenter. However, my use wasn't merely gratuitous. I used other images of Angelina (and Brad) throughout the talk as an anchor point, serving two purposes. First, because everyone laughs up front, seeing a similar image reminds them of that, making it more likely they'll laugh again. The other purpose was to pull the narrative along. Bringing up a topic early in a presentation, then allowing people to forget it, then bringing it back at an unexpected time is one of my favorite techniques in presentations. It allows attendees to make connections between disparate things that have more impact when you "force" them to make the connection themselves, rather than beating them over the head with it. For example, I brought Angelina up again when talking about demand for developers outstripping the supply, showing a publicity photo of her in the movie Hackers. This is a not so subtle anchor point that hopefully makes people realize that one of the reasons that the developer demand outstrips supply is the paucity of female developers, which hopefully makes people ponder that a bit. I use Angelina (and, to a lesser extent, Brad) throughout the talk as those kind of anchor points. Now, realize, these images are in no way pornographic. They are just publicity photos of famous actors. However, I was sensitive to the fact that some women might find this unsettling, so I made a deal with myself: if anyone every complains about those images, I'll remove them (and restructure the talk) with no questions asked.

That happened earlier this year. One attendee at a keynote wrote me a very nice note afterwards telling me that she wasn't comfortable with the imagery of Angelina in the talk (and that the presence of Brad didn't help). That was my cue to stop using that imagery and find other anchor points to make my points. Her email made me realize the pervasiveness and toxicity of this kind of imagery, and that, while convenient, it was ultimately just laziness on my part. Why do you think that so much entertainment falls back on sex and violence to keep people interested in otherwise pretty dull drivel? Watching a show like The West Wing), which doesn't traffic in that kind of stuff, shows that quality writing doesn't have to fall back on gratuitously titillating material. Ultimately, using sexually provocative material in a technical presentation is just lazy -- when we do it we're not spending the time to come up with really compelling metaphors to represent something, relying instead on the basest of currency. Presenters, myself included, need to do better.

Lots of people who aren't affected by this will say that this is a tempest in teapot, and that the offended parties are over reacting. Insidious misogyny is like lazy racism: people who engage in it hide behind a casual facade of "Oh, really, that was offensive"? Yes, by the way, it was.

Let me re-iterate a point: this isn't about Rails or the Rails Community (I still haven't gotten my official code ring and Certificate of Membership for this "community", by the way). On average, presenters at Ruby and Rails conferences put a lot of effort into creating compelling presentations, paying attention to metaphor, presentation style, compelling imagery, etc. The conferences where I attend the most talks are Ruby/Rails and the Tri-Fork conferences (JAOO and QCon. Kudos to presenters that care about creating compelling presentations. Only sometimes pushing the envelope on what's edgy entertainment crosses a line, which is what happened in this case. It could happen at any technical conference where the presenters are pushing hard on the creative aspect of technical presentations.

I strive not to be lazy when I put together presentations, to find compelling metaphors that don't inadvertently offend entire groups of people. I think it is an important maturity step for engineering and software communities to vote with their feet: outrage only goes so far, but notifying those who lazily offend effectively sends the message that it's not OK.

Guerrilla SOA (SOA & The Tarpit of Irrelevancy)

2009-04-22T04:38:00.002-05:00

This is the sixth in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. For those who are behind, you can read the previous installments here:

In all the previous posts, I've been basically elucidating all the reasons why I think that most SOA projects are a quagmire: mis-understanding the goals of why you are involved in this approach, the way most vendors are poisoning the water by selling ridiculously complex tools and services, why it's so seductive for developers who fetish complexity to get knee deep in these projects, and hype. If you read all these posts back to back, you'll surely have the impression that I think all hope is lost for enterprise integration.

But it's not.

Just like any software project, it is possible to do SOA right. My colleague Jim Webber has done lots of outstanding work in this area, under a rubric called Guerilla SOA. The basic ideas are:

treat SOA projects like any other project, and apply the same agile principles: continuous integration, testing, simplicity

don't use tools just for the sake of using tools. Try to keep the tool stack as simple as possible, and as automated as possible

use loosely typed endpoints and document/resource orientation to allow the different parts of your architecture evolve independently

It's best said from Jim's own mouth. Jim's British, so when he curses in technical presentations, people just think it's quaint (whereas when I do it, it's crass).

This is the way we generally approach SOA project: like other pursuits. SOA doesn't have to be a huge scary thing. It's just software, and we aren't going to throw our playbook out the window just because it sounds scary.

The term SOA has been so co-opted by vendors trying to sell stuff that I think it will die off as a term. We'll still be doing soa (note the lower case letters), but we'll have develop another three-letter acronym because the old one has slipped into the tarpit of irrelevancy.

Speaking at the Colgne JUG Monday, April 20th

2009-04-11T05:56:00.003-05:00

I'll be speaking at the Cologne Java Users Group on the eve of the JAX Conference, on Monday, April 20th at 7 PM. I'm letting the JUG organizer pick the topic, so I'm not sure what I'll be talking about, but I'm looking forward to it: I've never spoken at a German JUG before. If you're in the neighborhood, stop by and we'll geek out, then have a real beer afterwards.

Update: Here is a link to the slides I presented at the JUG. Thanks for having me; I had a great time.

Real World Refactoring in NFJS the Magazine

2009-04-09T04:37:00.000-05:00

Several people have asked me what ever happened to the NFJS Anthology book series (The NFJS Anthology, Volume 1 and The NFJS Anthology, Volume 2: What Every Software Developer Should Know. Both books contained essays built around some subject speakers were passionate about that year. Alas, the publishing business being what it is, there wasn't enough demand to justify continuing the series.

After much discussion, it was decided that the series would be more dynamic in magazine form rather than book form, which explains the formation of the NFJS the Magazine. This is a monthly publication written by NFJS speakers about something they are talking about this year, and of course something they are interested enough to speak and write about. Being in an magazine format makes it a bit easier to keep up to date, and the volume of material is higher because you get several articles a month.

I have a Real World Refactoring talk in the upcoming issue, based on my talk of the same name this year. If you go to a No Fluff, Just Stuff show, you get a free copy of the magazine, but anyone can subscribe

RailsConf Interview by Chad Fowler with Paul Gross and me

2009-04-06T23:53:00.000-05:00

One of the marketing tools that RailsConf uses is a series of interviews with upcoming talks. Chad sent some interview questions to Paul and myself around our upcoming talk Rails in the Large: Building the Largest Rails Application in the World, and he's posted it on his site. Want some opinionated conversation about Rails and how to use it to build Enterprise applications, then here it is (and we didn't use an Scala!). Enjoy!

The Triumph of Hope over Reason (SOA & The Tarpit of Irrelevancy)

2009-03-23T10:42:00.002-05:00

This is the fifth in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. For those who are behind, you can read the previous installments here:

A very funny site shows that this Internet thing might not be a fad. The Chuck Norris Facts web site has lots of great hyperbolic claims about Chuck Norris, American actor and legendary bad-ass. Some of the "facts":

If you have five dollars and Chuck Norris has five dollars, Chuck Norris has more money than you.
There is no 'ctrl' button on Chuck Norris's computer. Chuck Norris is always in control.
Apple pays Chuck Norris 99 cents every time he listens to a song.
Chuck Norris can kill two stones with one bird.
When the Boogeyman goes to sleep every night, he checks his closet for Chuck Norris.

Some of this may be just a tad exaggerated. I'm pretty sure that when Chuck Norris does pushups, he is not in fact pushing the earth down instead of pushing himself up. The site is here, if you want to go read more of them. I'll wait.

OK, now that you understand more about Chuck Norris, here's another site of over-the-top exaggeration about an over-hyped subject: SOA Facts, modeled after Chuck Norris Facts:

SOA is the only thing Chuck Norris can't kill.
SOA invented the internet, and the internet was invented for SOA.
SOA is not complex. You are just dumb.
SOA can always win at TicTacToe. Even if you go first.
One person successfully described SOA completely, and immediately died.
In a battle between a ninja and a jedi, SOA would win.
SOA knows what you did last summer, and is disappointed that it wasn't SOA.

I used a bunch of these in one of my SOA talks as bumper slides between the various topics, which provided a nice fun icebreaker. But I reserved two of them for the last part of the talk because I think they aren't exaggerations at all, merely deep truths:

Implementing SOA for the first time is the triumph of imagination over intelligence.

Implementing SOA for the second time is the triumph of hope over experience.

SOA has gotten so complex, with so many moving parts, that getting it right is extraordinarily difficult. Once you've lived through one of these projects (especially if you've fallen into the other tarpits I discuss in the previous installments), you understand the first quote at a deep level. That you would try it again truly is the triumph of hope over reason.

Rubick's Cubicle (SOA & the Tarpit of Irrelevancy)

2009-03-10T11:36:00.002-05:00

This is the fourth in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. For those who are behind, you can read the previous installments here:

Developers love to solve puzzles. One project manager with which I used to work kept a jar full of little nail puzzle (like this) on his desk:

Any time he was having a conversation that he didn't want developers to listen in on, he'd grab one of the puzzles and toss it to them. Inevitably, the developer would grab the toy and immediately become totally absorbed in solving the puzzle. After about 10 minutes, the puzzle would yield up it's secret, and the developer would look up and ask "Did anything important just happen?"

Developers tend to be problem solvers -- it's one of the appealing things about fiddling with computers. But what happens when you take a natural problem solver and present them with dull work, with no interesting challenges? What happens frequently is what I've deemed the Rubick's Cubicle anti-pattern.

If the presented problem isn't complex enough, developers will figure out ways to make it complicated and therefore challenging.

Writing the same dull CRUD application over and over is boring. But what if you could figure out a way to get all the simple CRUD applications to talk to one another? That's a nice and juicy puzzle. This perhaps explains the complexity fetish I see in so many "Enterprise" architectures and applications. Some of it is accidental complexity, accrued from years of piecing together parts that were never meant to work with one another. But I don't think accidental complexity covers the entirety of why things are so convoluted.

I remember back in the mid-90s, I was the CTO of a small training and consulting company. We were absolutely delighted when we first saw EJB: here was a technology no one could understand without extensive training. The same thing happened with all the variations of COM, DCOM, and CORBA. Those were flush times for training companies because we knew that developers would be drawn like moths to a flame, frequently with the same result.

Building the simplest thing that can work is sometimes duller than crafting some devilishly complex Rube Goldberg machine, but keeping it simple is a worthy challenge in it's own right. If you find yourself in Rubick's Cubicle, stop and ask yourself: "is there a simpler way to do this? Perhaps dismantling something that no longer serves it's purpose? What is the simplest thing that could possibly work?"

Emergent Design & Evolutionary Architecture at DeveloperWorks

2009-02-24T10:29:00.001-05:00

For the last few months, I've been toiling away on an article series for IBM DeveloperWorks, and it's rolling out today! From the abstract for the series opener:

This series aims to provide a fresh perspective on the often-discussed but elusive concepts of software architecture and design. Through concrete examples, Neal Ford gives you a solid grounding in the agile practices of evolutionary architecture and emergent design. By deferring important architectural and design decisions until the last responsible moment, you can prevent unnecessary complexity from undermining your software projects.

The first two articles in the series appeared today:

Evolutionary architecture and emergent design: Investigating architecture and design

Test-driven Design, Part 1

I plan to use this series to start a conversation about something that we all do everyday that we can't really describe well, even to other technical people (much less our grand parents). I don't supposed to know the answers (I'm not even sure I know all the questions), but at some point we have to talk about it. In the first installment, I provide some working definitions and some overarching concerns. Let me know what you think about it.

Speaking at the IT Architect Regional Conference in Atlanta

2009-02-16T17:26:00.002-05:00

At the end of February (the 25th - 27th), I'll be making a rare Atlanta conference appearance at the IT Architect Regional Conference, hosted by the International Association of Software Architects (IASA). This is the first in a series of regional conferences focused on an important but generally neglected segment of the developer population, software architects. What that title actually means is some matter of debate (hey, maybe this conference will help define that term), but the topics covered certainly trod some important ground. I'm doing a short version of my Smithying in the 21st Century keynote (overviewed here). My ThoughtWorks colleague Steven "Doc" List will also be there, imported from the west coast, convening an open space called Beyond Fight or Flight: Meetings Don’t Have to be Gladiatorial Combat, which sounds quite interesting. It's still not too late to sign up for it; hope to see you there.

Tools & Anti-Behavior (SOA & the Tarpit of Irrelevancy)

2009-02-06T12:08:00.002-05:00

This is the third in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. For those who are behind, you can read the first installment and second installments.

While rank and file developers go to conferences to soak in deep technical content, their peripherally technical managers (the ones who wrote some rockin' good Cobol code back in the day, but now they make decisions about modern enterprise architecture) go to different conferences in Palm Springs. At those conferences, they have a 2-hour morning session, run by a big tool vendor, then play golf for the balance of the afternoon. And what the vendors show them is poison.

Mostly what they see these days are tools that support SOA and ESBs. And in particular, the favorite demo-ware application is their BPEL (Business Process Execution Language) designer. This designer allows you to wire together services by drawing lines between boxes. The lines can include transformations and other sexiness. And it demos great. "Look, just draw a couple of lines here and here, click on the Run button and voila! Instant SOA".

Then, the manager brings it back home and notifies the developers that this is the new tool of choice. When developers start using it, they realize the awful truth: they've been sold a hairball generator. Tools like this work great on really small scales, when it's easy to see all the connections between things. But, as things get complicated, they start suffering from the hairball effect: all the lines start running together, and you can't create a diagram that makes sense to anyone anymore. Perhaps maybe you can fight through this, by creating workflows in chunks, and zooming in and out.

Then reality arrives. Because you create workflows using these tools, you are coding, in the worst possible language (a graphical representation). Thus, you are defining behavior, just like you do when you write source code. But the behavior you define lacks all the benefits you get from writing it in code.

reuse: you can't really reuse portions of your workflow because their is no method or subroutine functionality (you might get lucky with a sub-workflow). Mostly, people achieve "reuse" by copy and pasting, which you never do in code.
refactoring: no refactoring, making it harder to identify common workflow chunks for reuse. When you don't have refactoring, you don't watch for opportunities for refactoring as much.
limited programmability: you don't get if statements and for loops, you get whatever this particular BPEL designer supports. You get flow-chartly looking stand-ins for real decision statements, but they are much more brittle than the facilities offered in modern languages.
testing: you can't write unit, functional, or integration tests for these workflows. The only real testing option is user acceptance, meaning that the entire universe must be up and running. If you have no unit testing, you also don't have mock objects or other testing techniques common in code.
hard to diff: lets say you fought the beast and get a non-trivial workflow up and running, and everything is great. In six months, you change it in non-trivial ways, and all is good. Then it comes time to see what's different. BPEL tools don't have diff facilities, so you can either visually diff the diagrams (yuck) or diff 2 10,000 line XML documents (double yuck). BPEL relies on either heavy-weight diagramming tools or raw XML, and nothing in between.

Tools like this fall into the category one of my colleagues identified as doodleware tools. They let you create pretty pictures but collapse under scale. And they don't support all the common facilities offered by good old fashioned code. Is it really worth giving up robust reuse, refactoring, testing, programmability, and versioning/diffing just to see the pretty picture? Ironically, it's pretty easy to generate a similar picture from code, using tools like GraphViz.

I am a strong believer in the mantra

Keep behavior in code.

We have great tools for code (including ways to generate doodles) -- why would you want to abandon what works for something new and shiny? Except, of course, that code won't take you out for a golf outing in Scotland if you choose it.

On the Lam from the Furniture Police at Agile Atlanta

2009-02-01T14:42:00.001-05:00

I have two keynotes this year that I'm presenting at one conference or another. The first out of the gate was my talk entitled On the Lam from the Furniture Police at the Code Freeze conference. This talk has multiple parent ideas. The first derives from the book The Productive Programmer. It turns out that when you write a book about something, you get really immersed in the subject matter. That's obvious. What's less obvious is the inability to turn that overwhelming interest off after the book is done. That can either be good or bad. Once I had finished Art of Java Web Development, I pretty much never wanted to see another web framework! But the Productive Programmer was different, I guess because it's such a broad and unsolved problem. For whatever reason, I'm still soaking up Productive Programmer stuff.

The other parent of this talk involves the intersection of agile software development and productivity. While there's a little of that in The Productive Programmer, I wanted to keep the focus mostly on developer productivity in the book. But that's where On The Lam from the Furniture Police fits. This talk discusses how to be productive in corporate environments, including broader topics like agility. Here's the abstract:

When you were hired by your current employer, you may think it's because of your winning personality, your dazzling smile, or your encyclopedic knowledge of [insert technology here]. But it's not. You were hired for your ability to sit and concentrate for long periods of time to solve problems, then placed in an environment where it's utterly impossible to do that! Who decides that, despite overwhelming evidence that it's bad for productivity and people hate it, that you must sit in a cubicle? The furniture police! This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to gird yourself against all those distractions. I talk about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the mid-guided attempts to sap your ability to produce good work. And I give you ways to go on the lam from the furniture police and ammunition to fight back!

Every time I make changes to this talk, it's to enhance it's agile focus. So it's perhaps not surprising that I'll be giving a preview of this keynote at Agile Atlanta on Tuesday evening, February 3rd. If you're in Atlanta and interested in how productivity and agility intersect, stop by. And if you can't make it there, the next scheduled appearance is in Las Vegas, as the opening keynote of The ServerSide Symposium.

Why You Should Attend RubyRx

2009-01-28T09:03:00.000-05:00

I attend a lot of conferences as a speaker, covering Java, .NET, Ruby, and Agility (plus a few other random topics). The most obvious differences between all these conferences are the technical topics, but other surprising differences exist as well. One of the most striking is the presentation style and content of the Ruby conferences. The quality of the presentations at Ruby conferences is nothing short of stunning. They tend to have not only fascinating topics, but really compelling presentation skills. It's as if everyone at Ruby conference have read and internalized Presentation Zen by Garr Reynolds. No bullets in sight, lots of images, cool transitions, and just generally entertaining. It helps that virtually everyone at Ruby conferences use Macs, and therefore Keynote, which is light years ahead of PowerPoint. Keynote alone won't make a great presentation, but it certainly helps.

Not surprisingly, the worst conferences are those that force the speakers to use hideous conference-themed slide decks. Some conferences force you to create your presentation using a hideous template, then have some clueless intern enforce their misguided rules (up to the point of making changes to the slide show). The worst by far is Microsoft's TechEd. First, you must use PowerPoint (not too surprising, I guess). But last year I took a lot of time making slides with lots of images, centered text, and other transition tricks...only to have them disappear before my talk at the hands of someone who didn't have a clue. They literally took slides upon which I had big, centered text to emphasize a point and changed them to a slide with a made-up title and a single bullet point. This ham-handed treatment of my material is why I'm not doing TechEd this year.

But I digress. Ruby conferences on average have stellar presentations. And the RubyRx conference in Raleigh in late February sounds like it's going to be the exemplar of outstanding talks. It combines the expertise of the No Fluff, Just Stuff conference organization with a great lineup of speakers, including Matthew Bass, David Bock, Chad Fowler, Stuart Halloway (talking about Clojure!), Yehuda Katz, Russ Olsen, Jared Richarson, Venkat Subramaniam, Bruce Tate, and Glenn Vanderburg. And I'm going to be there too, like a kid at the adults table.

RubyRx sounds like it's going to be the great early 2009 Ruby conference. Come see what the fuss is about, both technologically and presentationally.

Upcoming Keynote: Smithying in the 21st Century

2009-01-21T23:12:00.002-05:00

I have two keynotes that I'm giving at various conferences this year. The first out of the gate was On the Lam from the Furniture Police, which I debutted at the Code Freeze conference in Minneapolis -- I'll have more to say about this keynote in a future blog post when it's about to appear again.

Smithying in the 21st Century comes next. I love metaphorical titles, and this one harks back to the changes in the blacksmith profession just after the turn of the century (in this case, the 20th one). If you were a blacksmith 1890, you had a terrific career path. However, once automobiles came along, the profession gradually diminished to a shadow of what it was.

Here's the abstract:

Blacksmiths in 1900 and PowerBuilder developers in 1996 have something in common: they thought their job was safe forever. Yet circumstances proved them wrong. One of the nagging concerns for developers is how do you predict the Next Big Thing, preferably before you find yourself dinosaurized. This keynote discusses why people are bad at predicting the future, and why picking the Next Big Thing is hard. Then, it foolishly does just that: tries to predict the future. I also provide some guidelines on how to polish your crystal ball, giving you tools to help ferret out upcoming trends. Don't get caught by the rising tide of the next major coolness: nothing's sadder than an unemployed farrier watching cars drive by.

I'm debutting some form of this one twice in 1 day! I'll give a short version of this keynote at the International Association of Software Architect's ITArc Atlanta Regional Conference as 1/2 of the opening keynote on Friday morning. Then, I get on a plane and fly to Milwaukee, where I'm scheduled to give the first real version of it as part of No Fluff, Just Stuff Greater Wisconsin Software Symposium. The research has been a blast, and I'm looking forward to putting it in front of people. There should be some interesting surprises lurking...

Standards Based vs. Standardized (SOA & the Tarpit of Irrelevancy)

2009-01-11T16:11:00.000-05:00

This is the second in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. The first installment is here.

Back in the very early days of Java web development, interacting with the tools sucked. Every servlet engine vendor had their own deployment scenario, and they varied wildly between vendors. I worked on several projects where we moved a web application from one dysfunctional servlet engine to another (this was in the early days, and they all sucked in one way or another). Then, the J2EE standard came along, including the WAR file format. Suddenly, you had a fighting chance (well, after a few iterations of the standard) of deploying to multiple application servers (notice how "servlet engine" became "application server"). And the vendors hated that.

They hated it because the J2EE standard turned their application servers into commodities. And the price of commodity software quickly approaches zero. That's why the application server vendors immediately started building more elaborate stuff on top of J2EE: portlet engines, content management, elaborate load balancers, etc. They knew that something like JBoss would come along and support the J2EE standard, making it impossible to charge $17,000 per CPU to deploy their application server (this number sticks out because one of my clients in the early 2000's paid WebLogic exactly that...for 8 CPUs). The J2EE standard essentially ran the server vendors out of the business of supplying just an application server.

Contrast that with database vendors. They are still able to charge big bucks for their servers, and keep companies (sorry, Enterprises) on the upgrade treadmill. An ANSI standard for SQL exists but (and this is the key part) it is so weak that it's useless. When last I checked, the ANSI standard for SQL didn't even include indexes, and no one would reasonably deploy a database server without indexing. The database vendors dodged the commoditization bullet by ensuring that the SQL standard would remain toothless in perpetuity.

Now, let's apply this to Enterprise Service Buses. One of the bits of marketing mantra touted by all the vendors of these Rube Goldberg machines is "standards". And they're selling these things into Java shops accustomed to the J2EE standard, so companies equate "standards" to "works the same across all players". All these shops are thinking of standards under the J2EE light, not the database server light. But here's the rub:

 ESBs are standards-based but not standardized.

This distinction is important. All the extant ESBs use standards in every nook and cranny, but it's all held together by highly proprietary glue. The glue shows up in the administration tools, the way their BPEL designer works (along with their custom BPEL meta-data), how you configure the thing, how you handle routing, etc. The list goes on and on. These vendors will never allow the kind of standardization imposed by Sun in J2EE. The last thing the vendors want is to see their (crazy money making) babies turned into commodity software again. They'll make noise about creating a true standard, but it won't happen. They want to be more like the database vendors, not the application server vendors.

Even the open source offerings in the ESB space suffer a little from this because they are giving the bits away and selling consulting and training. This is a good business model (look what it's done for JBoss), but they have the same motivation to keep you locked into their version of proprietary glue.

Having proprietary glue is not necessarily a bad thing. It's one of the factors you have to consider anytime you are thinking about turning part of your infrastructure over to a externally developed piece of software. Obviously, no one is going to build their own database server -- it makes good sense to buy an existing one, and fight the nasty battle if and when it comes time to move to another one. BUT, you need to understand the distinction between standards-based and standardized so that you don't buy yourself into a real long term nightmare.

Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)

2009-01-02T13:10:00.000-05:00

This is the first in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. The first installment is about how the need for SOA arose: tactics vs. strategy.

No company starts out as an Enterprise, they all start as a company, with just a few employees. As such, their IT needs are small, handled by a small group of developers who can chat with each other over lunch about what's going on in the IT "department". As the business needs software, they have some process to get the requirements to the developers, and they write code. Thus, the accounting department comes to the developers and says "Here are our requirements for our new accounting application", and the developers build some version of it. Inside that application are some small parts of something that the entire company cares about, for example, some of the aspects of customers. Meanwhile, the marketing department comes to the developers and says "We need an application, and here are the requirements", and the developers build it. Of course, this application also encapsulates some aspects of a Customer (not the same as accounting, but possibly with some overlap). It is rare indeed that anyone looks around and tries to come up with a comprehensive strategy for application interoperability: you don't have time for that -- you're a small company, and if you don't get your software, you'll go out of business. This goes on for a while.

Then, one day, you wake up, and you're an Enterprise. The CIO looks around with dismay at all the actual entities the corporation cares about because they are scattered in bits and pieces in all these different siloed and packaged applications. And the database stuff is a mess, with shared tables and views and ETL jobs running on cron jobs. And the CIO throws up in his mouth, just a little. The CIO looks at the landscape, and realizes that the technical debt incurred over the last few years can only get worse from here, so he calls out "Help." Big software vendors are highly attuned to people in big companies (sorry, Enterprises) who can write checks saying "Help". They ride in with a solution wrapped around the SOA moniker. More about our friends the Enterprise vendors in a future part of the series.

What I'm concerned about in this post is the overall landscape, which is another way of asking "How did you get where you are now?" You got here because of 2 reasons: first, you took the path of least resistance when you were a company (before you became an Enterprise) because, if you had taken the time to build a comprehensive strategy, you'd have never survived as a company. Second, and more important, what is strategic to the business is always tactical to IT. Business people can go into a conference room and change the entire direction of the company in 2 hours. Or, the business may decide to merge with another company that has truly dysfunctional IT, but other business concerns override that. IT can never move as fast as the business, with means that IT always has to respond tactically to the decisions and initiatives brought forth from the business. No matter how much effort you put into a comprehensive, beautiful, well-designed enterprise architecture, it'll be blown out of the water the first time the business makes a decision unlike the ones that came before. The myth of SOA sold by the big vendors is that you can create this massively strategic cathedral of enterprise architecture, but it always falls down in the real world because the COO (and CEO) can override the CIO (and his sidekick, the CTO). If you can convince your organization to allow IT to set the strategy for what capabilities the business will have long-term, you should. However, your more agile competitors are going to eat your lunch while you build your cathedral.

Any enterprise strategy you implement must realize that you will always be in tactical mode in IT because the business strategy doesn't require physical labor. Any enterprise architecture you develop must allow the business to evolve according to it's wants (and needs). This is what my colleague Jim Webber calls "Guerrilla SOA" and what I call "Evolutionary SOA". More about the details ofp evolutionary SOA in upcoming installments.

Conferences in Emerging Tech Countries

2008-12-11T11:09:00.002-05:00

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.

Irrational Artifact Attachment

2008-12-01T00:41:00.000-05:00

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.

Generative Ambient Music: Bloom

2008-11-17T14:52:00.001-05:00

One of the techniques I describe in The Productive Programmer is focus, distancing yourself from the all too common distractions in modern office environments. I suggest that you can wear headphones (or earbuds) while coding as an indicator that others shouldn't bother you. Some developers can code to music (in fact, some developers have a hard time not coding to music), but others fine it distracting. If you are in either group, you should try ambient music. The goal of ambient music is to create non-offensive background music. I find Muzak-style background music incredibly annoying and distracting, partially because they always choose sappy music (or taking good music and sappifying it) and partially because of a personality quirk described here. Ambient music strives to create a sonic background that not only doesn't distract but qualifies as good music. You can search for ambient music as a category on Amazon. Ambient music frequently uses techniques borrowed from Minimalist music, where you create a melody (which is too stong a term for some minimalist music) that repeats with minor variations.

Brian Eno is one of the pioneers of ambient music. He and Robert Fripp recorded the track The Heavenly Music Corporation on the album No Pussyfooting in 1972 by combining some experimental tape loop techniques from Eno, combined with Fripps guitar loops (called Frippertronics). No Pussyfooting is still available, and quite enjoyable. But the interesting part about it for this post concerns how it was created. Once Eno and Fripp had all the equipment set up, they started the tape loops and recorders for the background track and retired to Eno's front room and drank tea while the album recorded itself. No Pussyfooting has some early examples of generated ambient music (they were certainly not the first to experiment with generated music, but the first in a main-stream context). Eno and Fripp created several albums together. Eno has created a large catalog of ambient music (including the classic Music for Airports, recorded by several ensembles including the incredible Bang on a Can All-stars), and Fripp expanded the ideas behind Frippertronics using electronics for a stunning collections of recordings called Soundscapes.

Which brings me finally to Bloom. Bloom is an iPhone application created by Brian Eno and Peter Chilvers. When you launch Bloom, it starts a gentle drone sound as a background, and gives you the option to create ambient music by tapping the screen. When you tap, a note plays based on the location of your tap. You can tap single notes or chords. After about 5 seconds, the note repeats and continues while it gently decays. Using Bloom, you can create your own ambient music. I can play with Bloom for hours. It is one of the best iPhone applications I've found: a trully innovative application that takes great advantage of the iPhone interface.

The other option when you start Bloom is for it to generate music for you randomly. That brings us back around to focus. Using Bloom, you can generate unique, non-distracting music for an entire day. Rather than buy a collection of ambient recordings, you can generate your own ambient music. Bloom lets you set several "moods", changing the tonal range and drone sounds to add just enough variety in the music to keep it just interesting enough to not distract. What used to take tons of studio equipment now runs on the iPhone. This makes a great way to help enhance your focus in noisy environments. Allow Bloom to create music for you that doesn't distract yet effectively drowns out all the other distracting sounds in your cube-ridden environment. Bloom is a great example that the iPhone isn't just another mobile device: it's a new platform for software development.

Comments == Code Smell

2008-11-07T15:27:00.001-05:00

I am sometimes asked about my position on code comments, and, like most things, I have strong opinions about it. Two kinds of comments exist:

JavaDoc-style comments (which encompasses JavaDoc, XMLDoc, RDoc, etc), which are designed to produce developer documentation at a high level (class and method names and what they do)

In-line comments, generally scattered around the code to indicate a note from developer to developer

Both kinds of comments represent different smells, each with different odors depending on the target.

What makes comments so smelly in general? In some ways, they represent a violation of the DRY (Don't Repeat Yourself) principle, espoused by the Pragmatic Programmers. You've written the code, now you have to write about the code. In a perfect world, you'd never hove to write comments for this purpose: the code will be expressive enough that someone who reads it will understand it. Two things help achieve this result: expressive, readable languages and the composed method pattern.

The language makes a big difference as to the readability of the code. If you write in assembly language, you're pretty much forced to write comments; no one on earth can read the code directly. As languages have matured, you can get much closer to the ideal of self-documenting code (which was explicitly attempted in Literate Programming). Especially in the modern wave of non-ceremonious languages (like Ruby, Groovy, Scala, etc), you can craft extremely readable code. To this end, ThoughtWorks projects generally avoid the more magical features of languages (like the implicit global variables in Ruby, for example) because it hurts readability. One of the side effects of dynamic typing is outstanding method names. The method name is the only vector of information about what the method does (you can't crutch on return or parameter types), so methods tend to be named much better on the dynamic language projects upon which I've worked.

The second key to readable code is not to have too much of it, especially at the method level. In Smalltalk Best Practice Patterns, Kent Beck defines composed method (which I write about extensively in The Productive Programmer). Composed method encapsulates the idea that all your methods should do one and only one thing, making them as small as possible. The side effect of this discipline leads to public methods that mainly consist of calls to a large number of very small private methods, each of which do only one thing. Composed method has lots of beneficial side effects on your code: small methods are easier to test, you end up with really low cyclomatic complexity for your methods, you discover and harvest reusable code chunks more easily, and your code is readable. This last one brings us back to the topic of comments. If you use composed method, you'll find much less need to have comments to delineate sections of code within methods (actual method calls do that), and you'll find that you use better method names.

Now let's talk about how this applies to the two types of comments. First, where are comments indeed useful (and less smelly)? If you are writing an API, you need some level of generated documentation so that people can use your API. JavaDoc style comments do this job well because they are generated from code and have a fighting chance of staying in sync with the actual code. However, tests make much better documentation than comments. Comments always lie (maybe not now, but on a long enough timeline, all comments will become outdated). Tests can't lie or they fail. When I'm looking at work in progress on projects, I always go to the tests first. The comments may or may not be there, but the tests define what's now done and working.

We were on a project where the client insisted on Javadoc comments for every public class and method. We started the project adding those comments, but eventually stopped. When doing agile development, you don't want anything that hampers refactoring. Having comments in place caused a dilemma: do I refactor the method and change the comment (the most work), refactor the method and leave the old comment (with the theory being that I'll change it again later, and would rather just have to update the comment once), or not refactor? No good options here. Having pervasive comments discourages refactoring because it adds significant extra friction. On this project, we abandoned commenting as we went along. The last week of the project we literally did nothing but go back and add comments to the code, which worked well because the code base had settled down by that point. But notice what's lurking in wait: the client wanted all the comments there to make it easier to maintain in the future. But who's to say that whoever maintains that code will keep the comments up to date? You have the same DRY violation as before. If they maintain the tests, they have to change as code changes because they are executable.

The new wave of Behavior Driven Development tools (like JBehave, RSpec, and easyb make this "executable specification" style of comment + test feasible. I expect to see the usage of these tools skyrocket because they give you documentation that has a fighting chance of staying up to date.

Inline comments are almost always a smell. The only legitimate use of inline comments is when you have some very complex algorithm that you need to have some thoughts about beside the code. Otherwise, the presence of inline comments indicates that you've written code that needs explanation, meaning that it cries out for refactoring. I frequently troll code bases upon which I'm working to look for inline comments so that I can refactor the code to eliminate the need for them.

Comments are a great example of something that seems like a Good Thing, but turn out to cause more harm than good. Fortunately, we've figured out how to achieve the same benefits that comments allegedly provide with tests, particularly BDD-style tests

Voices That Matter: Crafting Software Conference

2008-11-03T14:11:00.002-05:00

Just a quick note to let my readers know that I'm speaking at the Voices That Matter: Crafting Software Conference coming up in San Francisco in early December. I'll be speaking on Real-world Refactoring, and I'll be doing a pre-conference tutorial called 10 Ways to Improve Your Code. This is based on material from The Productive Programmer and my 90 minute conference talk of the same name, but I'm expanding it to 3 hours. That shouldn't be hard because there's a lot of rich material there, and 90 minutes always made it hard for cramming in that much information Now, each topic can spread its wings more.

Of course, I don't mention every conference for which I'm speaking in my blog (otherwise, it'll be nothing but conference announcements). I bring this one up because you can get a discount: use CSNPKRA as the priority code when you register and, lo and behold, a discount! Don't ever say you never got anything of value from this blog!

Code, Forrest, Code!

2008-10-22T15:40:00.001-05:00

The movie Forrest Gump has been re-playing a lot lately, and, as often happens, I see parallels in the software industry (I've learned not to bring these up to my wife so that I don't get the look). Of course, Forrest was mentally challenged, yet he had a wildly improbable life. The real point of the movie is the exploration of destiny vs. free will, as exemplified by the feather that floats freely, is captured and carried to new places in the Curious George book, and then floats free again. But that's not the point of this blog entry.

How did the mentally challenged Forrest achieve so much? Total concentration. If you notice in the scene where he first learns to play ping pong, the guy showing him says "The most important part of this game is to never take your eye off the ball". As soon as he says that, Forrest squints his eyes and starts concentrating hard on the ball, and starts hitting it. Of course, in the movie, he eventually becomes a celebrated table tennis player, going to China, meeting the president, etc. The events in the movie are highly improbable of course, but the writer had to come up with some talent that Forrest had that would enable all his amazing feats. And that was flow. I talk about flow in The Productive Programmer (in the Focus chapter) as defined by Michael Csikszentmihalyi. Flow is a state intimately familiar to all developers. It's that state of total concentration, where time disappears and you get your best work done. In fact, Csikszentmihalyi argues convincingly in his book that flow is the secret to a happy life: finding things that are challenging enough to engage your full concentration but not enough to be persistently frustrating. The ability to get to this state explains why so many developers love their career. Software development offers lots of opportunities to get to this state, offering puzzles that are always just within reach.

But flow doesn't come for free. It's a psychological state, meaning you can't just force yourself into it. My friend Brian Goetz has the best comparison I've heard: flow is like sleep. You can't force yourself to go to sleep, but you can set up the environment to make the state easier to achieve. That's one of the reasons people have so many rituals around bedtime. Flow is the same way. You can't force it, but you can set up the correct environment. Brian explained this to me in the context of interruptions. When he works at home and his family interrupts him, he's grumpy because they've broken his flow. But they don't understand: it's only a 5 minute disruption. But his killer analogy? What if someone awoke you 4 or 5 times a night for just 5 minutes at a time? You'd have a terrible night's sleep.

This matters a lot because perhaps the most hostile environment for flow is cube land. Putting developers (or any knowledge workers, for that matter) in a sea of cubes forces you to constantly deal with an environment that's hostile to getting to the state where you are most productive. Lots of developers have figured out how to survive (just like big city dwellers learn to sleep through noisy environments). One of my favorite lines from The Blues Brothers movie is when Jake comes "home" with Elwood, directly adjacent to an elevated train. Jake asks "How often do those trains run" to which Elwood answers "So often you won't even notice it!". How often do meetings happen in your office? So often you won't even notice that you only have about 2 hours a day to actually get work done. This is by the way one of the secrets to the effectiveness of pair programming. It is possible for 2 developers to get in flow at the same time. Because more than one person is working, external forces are less likely to disturb them, allowing them to stay in flow for long periods of time. This explains why, if you are new to pair programming, you are hammered after 8 hours of pairing: you've been in that deep concentration state for longer than what you are accustomed.

I talk about strategies for getting to and staying in flow in The Productive Programmer. That's the secret to real productivity when coding. Be like Forrest Gump: learn how to achieve that deep, deep concentration state in your environment (or, if you can't change your environment, change your environment). Code, Forrest, Code!

Library Oriented Programming

2008-10-06T14:56:00.000-05:00

Way back in 1968, Edsger Dijkstra almost caused a riot at the ACM conference. His audacious crime? "Use of GOTO considered harmful." No one there could imagine writing code without GOTO's. Yet, of course, within a few years, GOTO-oriented programming faded away, replaced by structured, modular, and object-oriented programming. Structured programming has become such the mainstream that we don't even refer to that feature of the language anymore: we never say that C is a "Non-GOTO" language.

Fast forward to today. In the same way that C isn't a "Non-GOTO" language, I contend that Java is no longer an object-oriented language. Sure, the object abstraction is still there, but it has sunk so far down into the infrastructure we don't even think about it anymore. This blog really drove it home for me: Java is a library oriented language. Think about it: when was the last time you downloaded a single class from the Internet to use in an application? Libraries and frameworks are the code reuse mechanisms in Java. Ultimately, the class is just too fine grained to really achieve reuse, but libraries can.

This explains tools like Maven and Ivy. While Java is a library oriented language, no good facilities exist within the language to manage libraries. Some work has been done on the "module" specification, but word from insiders say that is has essentially collapsed into two warring factions: the OSGI vs. Maven camps. Consequently, it looks doubtful that a module facility will appear anytime soon for Java. That's OK: we'll keep doing what we've always done while waiting for ratification of infrastructure -- use open source tools that solve this problem.

Ultimately, we need to embrace the idea of Java as a Library-Oriented Language. That means treat libraries (and dependencies between libraries) as first class citizens in your projects. Developers tend to try to avoid nasty coupling and circular references with classes, yet too often tolerate it with their JAR files. Looking at Java in this light forces you to think about how you create project directory structure (Maven helps with this, as well as tools like AppFuse, which creates consistent directory structures for different kinds of web applications). Convention over configuration was one of the "breath of fresh air" approaches from Ruby on Rails. It makes building tools and plugins for Rails easy because you can always rely on a standard directory structure for projects. Of course, it's too late now to create the universal standard Java project structure, but you can do this within your own company. Once you have a consistent structure, it makes writing little utilities that can do things to all your projects much easier.

Consistency is the key to automation.

A consistent directory structure for all projects makes it easy to plug into continuous integration, write test helper classes, manage dependencies across projects, and a slew of other benefits. Start treating Java like a library oriented language, think hard about dependencies, versions, and where things live. And, finally, create consistency across projects so that you can take advantage of economy of scale.

Remote Usability

2008-09-24T16:41:00.002-05:00

Ever since I read Don Norman's The Design of Everyday Things, I've been hyper-sensitive to things that have really poor usability. His classic example is doors: how often to you walk up to a door that has handles on both sides, tricking you into pulling instead of pushing? Doors like this require an instruction manual: "Push" or "Pull". But the problem is that, if it's a glass door, you'll read the backwards word through the glass and still do the wrong thing. It isn't you, it's the door. If something as simple as a door requires a manual, it's really poorly implemented.

Here's a recent case of something simple whose usability is so profoundly broken it needed a manual. I spoke at TechEd this year. They are one of the conferences that absolutely require that you use their machine for your presentation. On the stage, they had a remote control to use for your slides. It looks like the image to the left. Normally, the button the right moves to the next slide and the left button moves you one slide back. Yet this stupid remote reverses that. Of course, you can turn it upside down, but it clearly had a right-side up. To fix it? Someone affixed labels to it to fix the utterly broken usability.

As developers, we need constant diligence for usability. While it probably made perfect sense to some remote control creator because of the electronics to put the buttons on the wrong sides, but it ruins the usability. If a 2 button remote can't get this right, what hope do we have when building a rich client?

SOA (Sidekick Oriented Architecture)

2008-09-16T23:05:00.000-05:00

Warning: smiling broadly or laughing out loud while reading this will expose your age to those around you.

When Microsoft released DOS 3.3, they added a much requested feature: background printing. That was the state of the art of cool back then: at the time, DOS was a single-process operating system, and users complained that they couldn't do anything else while waiting for something to print. Thus, Microsoft added the print spooler. But that opened a can of worms, because other software companies (like Borland) reversed engineered what it did and built applications around it. The way it worked was by chaining to a low-level interrupt in the underlying plumbing of the operating system. Borland exploited this to create a massively useful little utility called SideKick. SideKick was awesome. While working in an application, you could hit a hot key and pop up SideKick, make a calendar entry, browse the file system, and lots of other stuff. Then, with a hot key, you were back in your application. This was old-school multi-tasking: incredibly primitive, yes, but oh so useful. This category of tool was categorized as a TSR's (Terminate and Stay Resident) application.

Of course, you can imagine what happened next: everyone and their brother built TSR's. And if you weren't careful with your interrupt chaining, the whole house of cards came crashing down. This became an annoying issue in the dying days of DOS. Windows rescued us because it had an event driven architecture, and you could run multiple applications at the same time. Of course, Windows was really just running on the shaky DOS ground, but it allowed developers to take advantage of the event driven system automatically and stop fighting with other applications over interrupts.

The problem with the TSR approach was the fragile high coupling it required for the limited resource of operating system interrupts. We know now (and then) that highly coupled systems are fragile. Yet we seem to never learn that lesson.

Look at the state of most "enterprise" applications today. You think you have 5 different applications that share the same database. In reality, you have one massive application, partitioned at the application layer but still highly coupled once you get to the database. It's hard to make changes to the shared database without breaking (or at least looking hard) at the existing highly coupled applications. In hindsight, I think we're going to regret the way we've tended to use databases in large corporate environments. Part of the problem is the myth of a single source of knowledge throughout the enterprise. I've talked to a bunch of CIO's who say "I don't care what you do in the applications you build, but my database schemas are precious". This is a short-sighted view of how to build flexible architectures. Much of the work done now in SOA is the attempt to untangle this mess. How did we solve the problem with TSR's? Event driven operating systems. And how are we going to fix enterprise architectures? The same way! Just as Windows (built on the foundation of DOS) gave us a sane way to do multi-tasking, event driven architectures built on the foundation of our ridiculously coupled databases will make "enterprise architecture" more sane. Eventually, we'll make fundamental changes (just like Windows did when it added true premptive multi-tasking) to make things even better.

This is one of several places that Ruby on Rails nailed the right answer dead on. One of the obvious-in-hindsight decisions Rails encouraged/enforced was the "1 application, 1 database" style of application. If you need 2 applications to share knowledge, you do it with ActiveResource and messaging between applications. Once you assume that style of application, so much gets easier. You can stop worrying about the nasty high coupling between application's data access and start thinking about what individual applications need to do.

It's going to take a long time to fix this, though. While TSR's and DOS was a bit of a mess, it was a pretty small scale mess compared to what enterprise architecture looks like now. Given the fetishization of databases and the flawed assumptions that people apply to how to use them, it's going to take the rest of our lives to untangle this mess. There are movements afoot to rethink this within the database community (exemplified by books like Refactoring Databases by Scott Ambler and Pramod Sadalage. Just like with TSR's, we need to rethink Sidekick Oriented Architecture.

Thanks for Flushing...er, Building

2008-09-06T22:06:00.000-05:00

When things are automated, you just forget about them. And that's a good thing: you'd rather spend your time thinking about important things, like "is my design correct" or "should I be refactoring now". Developers who haven't embraced continuous integration yet spend way too much time doing something (builds) that are better left to automation. At the No Fluff, Just Stuff shows, one of the Sunday poll questions for the crowd is "How many are using continuous integration?" I'm always depressed to see that it's generally less than half the crowd. I can't think of any single practice that makes projects better than CI. Moving from building your project as a bunch of snowflakes (if you build using an IDE, what you build will be subtley different than what your neighbor builds, thus you aren't building the same thing: each build is like a snowflake) to a single, canonical build allows you to stop worrying about build problems. If it fails on the CI machine, it's broken, regardless of what happens on your machine. It frees you from the "midnight before the big demonstration, everyone's standing around Fred's machine because his is the only build that works" anti-pattern.

Having all that noise automated just lets you forget about it. As I was using the restroom in our Chicago office, I saw the perfect metaphor for this. Most of the newer buildings you enter now have auto-flush toilets, so that you don't have to touch any of the surfaces. It's become so common, in fact, that you forget that step in places that don't offer automatic flushing. In our office in Chicago, in the public restrooms, you see the "Thanks for flushing" sign on the wall. What a perfect metaphor! When it happens automatically, you can forget about it. When it doesn't, you have to remind people that it's important for the hygeine and smell of the environment to do the right thing.

If you haven't already, install auto-flushers for your project, in the form of continuous integration, and start thinking about more important things.

The Music Project

2008-08-29T06:03:00.004-05:00

I was talking to my friend Brian Goetz recently, and he reminded me of a blog entry he posted a while back. He's digitizing his entire music collection, and he's done all the research. This is appealing to me because I recently switched over to zero reliance on the shiny plastic disks once I've ripped them. All my music consumption is now electronic, mostly via iPod (the car was the last frontier, and now that's switched over as well). I have a large-ish CD collection (~1500 CDs), so translating them to electronic form is no small feat. And I only have to do it once for the rest of my life.

Based on my conversations with Brian, I realized the following:

Ripping and encoding are completely separate activities
The most important thing is to get a reliable, error corrected rip
You don't want to get stuck with a proprietary format (as much as I love Apple, I don't want my music collection tied up in one of their formats forever)
Lossless is the way to go, so that you don't loose any data in this process
Cross-encoding allows you to rip your music in a "core" format and selectively support proprietary formats and reduced file sizes (and lossiness)

His original entry is about his Windows and Linux based infrastructure. I replicated his same setup (with minor differences) on the Mac.

A Home

First, you need a home for all these files. I recently got a network attached storage device to hold our growing collection of digital photos. I'm my family's tech support, and if anything ever happens to those photos, I'm a dead man! After doing a lot of research on quality, Mac compatibility (my household is 100% Mac now), I ended up with the NETGEAR RND4250 ReadyNAS, which comes with 500 GB of storage (2 mirrored 500 GB drives), with a capacity of 2 TB. I ended up bumping it up to a TB when I realized how big the combination of music + pictures would be, and the Netgear handled it beautifully.

Ripping

I didn't realize this, but most rippers don't take advantage of the error correction bits on the CD, and they are wimps: they give up way too easily. The trick is to find a ripper that is relentless and tries its hardest to get all the bits off the CD. The ripper/encoder I ended up using is Max, which supports Leopard in it's latest (allegedly) unstable form, and previous Mac OS X versions in it's previous (stable) release. I caveat "unstable" because I used it a lot and it was rock solid for me on Leopard. One of the nice things about Max is its support for different rippers: fast & carefree, or paranoid. The latter is the one I want, based on the cdparanoia project. You can configure this ripper to never give up until it gets a clean read of the disk. Several of my CDs trundled for 6-10 hours before Max finally reported success, including a couple that I'd given up for dead.

Encoding

OK, so now I have a good rip, I need to encode it (this post makes it sound like separate steps, but Max handles both for you). As I stated earlier, I don't want to get trapped by a specific format. I ended up (like Brian) choosing FLAC. FLAC is a open standard encoding for music that offers lossless compression, which is what I wanted. The FLAC spec also allows for more aggressive compression without loss of data, depending on your patience. It's designed to take longer to encode but have no impact on playback time. I choose the most aggressive because I have time, hardware (a MacPro with 4 processors), and I want to conserve space if possible. But, iTunes (which is how I play and sync my music) doesn't support FLAC. Max to the rescue: it will let you do parallel encoding. I set Max up to encode the ripped music files to both lossless FLAC and lossless MP4 (Apple's format). The only downside is that it won't allow you to choose different directories for the encoding. The FLAC files I'm placing on a RAID mirrored network-attached storage drive (remember, I never want to do this again!). So, I ended up writing a little Rake file to handle automatically moving the files from one place to another. I rip them all to the RAID drive, then let the script move them (preserving directories) to the other. The script is here, if anyone wants it (no warranty expressed or implied -- you'll have to change all the directories, and if you use this to erase your hard drive I'll shed a tear for you, but might just laugh).

task :copy do
count = 0
skipped = 0
FileList["**/*.m4a"].each do |f|
artist, album = recording_info_based_on f
if File.exist?  "#{DEST}/#{artist}/#{album}/#{File.basename(f)}"
  puts "\tsomething is amiss; I'm skipping: #{f}"
  skipped += 1
else
  FileUtils.mkdir "#{DEST}/#{artist}" unless File.exist? "#{DEST}/#{artist}"
  FileUtils.mkdir  "#{DEST}/#{artist}/#{album}" unless File.exist? "#{DEST}/#{artist}/#{album}"
  puts "#{artist} - #{album} - #{File.basename(f)}"
  count += 1
  FileUtils.cp f,"#{DEST}/#{artist}/#{album}"
end
end
puts "copied #{count} files\nskipped #{skipped} files"
end

def recording_info_based_on filename
File.expand_path(filename) =~ /.*\/(.*)\/(.*)\/.*/
return $1, $2
end

I also made a rake task to report any that ended up missing from the original FLAC directories to the AAC files (just in case something went amiss during a copy process, or I screwed up and deleted something by mistake). I want to make sure that the convenience Apple-format files match the canonical source (the FLAC) files. So, this is the "missing" rake task:


task :report_missings do
count = 0
FileList["**/*.flac"].each do |f|
artist, album = recording_info_based_on f
dest_file_name = File.basename(f).sub /flac/, "m4a"
unless File.exist? "#{DEST}/#{artist}/#{album}/#{dest_file_name}"
  puts "missing #{f.sub /\.flac/, ''}"
  count += 1
end
end
puts "found #{count} missing files"
end

Result

It took me about 2 months of ripping while I'm around my computer, running 2 computers (my laptop and desktop) in parallel. In the end, though, I ended up with 453 GB of music files, the FLAC ones safely tucked away on a mirrored drive and the M4A ones on my desktop, ready to be synced to my iPod (or a subset of them, anyway). Now, when I get a new CD, I rip it using Max to the NAS and either copy the files by hand (if it's just one CD) or use the Rake file to move lots en-masse. Storage is now dirt cheap, and I've leveraged almost a terabyte of it keeping the music files in 2 formats. I also recently bought a portable 500 GB drive so that I can keep all my music with me on the road. It's a copy of the desktop M4A files, but it's easy just to mirror the Music directory from the desktop to the portable drive.

I achieved my goal: an open archival format that I hope will be around for a very long time, and a convenience version for the way I happen to consume them today. And the shiny disks? I put them all in binders, so that if I ever need one of them (or it's sleeve), I can rummage around in the (mostly) alphabetical CD volumes. I didn't put a huge amount of effort creating an expandable storage that makes it easy to keep them in strict order because that would take lots of effort and it isn't something I expect to have to do often. If it turns out I got back to them all the time, I'll invest the time then.

97 Things Every Software Architect Should Know

2008-08-20T20:15:00.001-05:00

A while back, Richard Monson-Haelfel was working on a presentation called "10 Things Every Software Architect Should Know", which was a great idea for a talk. To solicit ideas, he posted to several mailing lists where architect-types lurk about, and he got flooded with responses. I was one of the early contributors because I had been thinking about some of this stuff anyway at the time he posted the call. Richard liked the entries so much, he decided to put up a wiki through O'Reilly to publish all these little snippets of advice (or axioms). O'Reilly liked the results so much that they are considering making it a book, sort of like Beautiful Code, but with much shorter (and many more) axioms. I'm not sure where the magic number of 97 came from, but that seems like a reasonable number. The whole "About" story appears on the site, here.

Well, it's out of the shadows now. O'Reilly has moved the site to NearTime (a sparkly hosted wiki site) and it's now public here. Go visit: there is some incredibly good advice here, in little bite-sized chunks. I greatly enjoyed reading the site and soaking up some of the great advice, all derived from real-world slings and arrows. Kudos to Richard for seeing this through.

In Praise of Technical Reviewers

2008-08-12T13:09:00.001-05:00

It came to my attention recently that I had made a bad assumption about the Productive Programmer book. My understanding (and apparently this is common) is that the technical reviewers of the book would get an entry on the title page of the book. Apparently, that's not the case. That's why I didn't put them in the acknowledgements: I assumed they had already been recognized. But they haven't, so I'm going to rectify it.

First, I've added a special paragraph to the acknowledgements in the 2nd printing of the book, thanking the hard-working technical reviewers. This is a little unusual (generally, nothing changes between printings, but I felt badly about this). The other thing I'm going to do is thank them here. This is the new paragraph in the 2nd printing:

A special thanks goes out to the technical reviewers for this book. Without their hard work and dedication, this book would suffer lots of silly mistakes and confusing explanations. Thanks to Greg Ostravich (who has reviewed every book of mine for the last few years and gotten no recognition, unfortunately), Venkat Subramaniam, David Bock, Nathaniel Schutta, and Matthew McCullough.

Greg gets a special thanks. He's reviewed everything I've written over the past few years, and circumstances keep preventing him from being acknowledged. In the 2006 No Fluff, Just Stuff Anthology (which he reviewed), I was under the same mistaken assumption that the reviewers got a shout out. In the 2007 No Fluff, Just Stuff Anthology (which he reviewed), I specifically wrote a thanks to him and the other reviewers. But, alas, the book came in too long, and several pieces got cut, along with my original introduction to the book (it was replaced by Ted Neward's). Unfortunately, the shout out got axed with the introduction. And, now, clearly demonstrating hope over experience, Greg volunteered to review the Productive Programmer, and the same thing happened. So while I'm thanking the other Productive Programmer technical reviewers, I'm both thanking and begging forgiveness from Greg. Good job, buddy, and unacknowledged for too long.

Rich Web Experience 2008 x 2

2008-07-23T11:22:00.001-05:00

Last year, one of the most refreshing conferences where I spoke was the Rich Web Experience. Too often, conferences are mono-cultures, and mono-cultures are generally boring. RWE is fundamentally different because it's what I call a condiment conference. The focus is on how to make applications better, not how to make the plumbing better. Nothing wrong with plumbing, mind you, it's just refreshing to look at faucets for a change.

This conference has an eclectic mix of developers. Hallway conversations lack the implicit assumptions you can generally make at main course conferences. For example, all Java developers have an implicit context. At The Rich Web Experience, you have to throw away your base assumptions, both in sessions and conversations. Just like travel broadens you because you meet people with different contexts and experiences, attending the Rich Web Experience does the same for technologists. Instead of the usual low-level animosity that each technology tribe exhibits for the non-tribe members, everyone focuses on common ground. This year, there are 2: one near the east coast and another on the west.

Finally Treeware

2008-07-16T15:18:00.000-05:00

OK, it's finally here. I got my copy of The Productive Programmer in the mail last week, and today Amazon updated it's status to "In stock". For all those who have been patiently awaiting this book, it's finally here. Finally! The first glimmer of this book started in 2005(!), so it's taken upwards of 3 years to convert what David Bock and I were talking about into actual tree-ware. Because it took so long to produce, I suggest that, if you are going to buy one, you should go ahead and buy 2, in case you lose one. And, of course, nothing says loving to your spouse like an O'Reilly book. A great gift for anniversaries, birthdays, bar mitzvah's, etc.

Even if you don't buy the book (and can ignore my bitter tears) and you still have an interest in developer productivity, you can head over to the Productive Programmer wiki and contribute.

Sony eReader Update: It's all Bad and Ugly

2008-07-10T18:14:00.000-05:00

Back in January of 2007, I wrote about my impressions of the Good, the Bad, and the Ugly of the Sony eReader electronic book reader. I thought I’d update that, given my time with the device and the eBook service. And the news isn’t good.

One of the major annoyances of the eReader is the inability to reflow PDFs. That’s a complex problem, so they get a pass on the actual reflowing part. The solution they offered was the ability to view PDFs in either of two formats: either the entire page or just the width of the text on the page. The latter worked reasonably well for most PDFs when viewed in the landscape mode of the eReader. But here’s the fatal bug: when you switch pages in the PDF view, it restores the “width of text” view to the “width of page” view, but doesn’t update the mode on the reader. Thus, you must hit the button to actually get it back to what it thinks is officially “width of page” view, then hit it again to actually get back to “width of text” mode. Page refreshes on the eReader are very slow, which isn’t a big deal when reading a book because you only have to do it occasionally. But forcing the multiple page switches just to restore it to the mode it says it’s on is deadly. It effectively made reading PDFs on the device unpalatable. I reported this back in my original review, and predicted that it would be fixed in a software update (leaving aside for the moment how the device could have ever shipped with such an obvious bug).

It never happened. The new version of the reader came out with no software update in sight for this killer bug. I don’t know if they’ve fixed it in the new version because, frankly, I wouldn’t take one if they gave it to me. They did offer to sell me a new one when my original died. I turned it on one day in December and the screen was a garbled mess. I contacted their support who told me that, since mine was out of warranty, my best course of action was to purchase another, new version. That’s never going to happen.

In fact, the whole experience has soured me on Sony. They used to compete in mind share at least with Apple for delivering innovative products, with a modicum of understanding things like design and aesthetics. Apparently, they’ve abandoned that. I still own a single Sony product, the PSP Portable, which embodies many good features and design touches. But seeing how they treat their customers for an admittedly small, trivial market is enough for me to cast all their products in doubt. They clearly don’t have any concept of quality assurance (given the original bug) or responsibility (never fixing it). It’s a shame too because reading actual eBooks on the reader wasn’t bad. I probably read about 40 books on it, and liked it a lot. But, given that you can’t read PDFs on it, and their eBook format is proprietary (another annoying characteristic about Sony — memory sticks anyone?), I won’t buy another one.

I’ve looked at the Kindle but haven’t taken the plunge yet. I want a killer user experience, and it doesn’t look like it. I wish Apple (or someone who understands design like Apple) would release an eReader so I could read the Neal Stephenson Baroque Trilogy without herniating myself!

Expert Panel at Agile Experience

2008-07-01T08:24:00.000-05:00

Last weekend, I spoke at the Agile Experience in Reston. It was a great conference, lots of interesting topics, and a different crowd than most technical conferences. Half the attendees were managers, and everyone was enthused about Agile development. The experience level with Agile was diverse too, so it was fun to get out-of-the-blue questions. My first talk was Real-World Agile, and I start that talk by soliciting the agenda from the crowd (I open up a text editor and make the group tell me what they want to talk about). That was great here because it let me understand the actual pain points for the attendees, and it makes for a more interesting presentation for me.

On Friday night, we had a wide-ranging expert panel discussion which ranged from methodology to soft skills to cultural fit. And it was recorded. Come hear me stereotype all Americans as assholes!

Communication Channels & Cell Phones

2008-06-27T12:44:00.002-05:00

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

2008-06-17T20:40:00.000-05:00

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...

2008-06-09T11:05:00.000-05:00

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

2008-06-02T09:46:00.001-05:00

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.

ThoughtWorks Anthology

2008-05-23T23:43:00.000-05:00

This isn't a book review because it's considered bad taste to review books in which you participate. But, The ThoughtWorks Anthology is an interesting project, and I thought I could provide some perspective on it's genesis. TWA offers a glimpse of why ThoughtWorks is such a cool place to work: lots of people passionate about technology, who care about changing the IT industry.

As you may already know, I compiled two other anthologies, the 2006 and 2007 No Fluff, Just Stuff Anthologies (editing is too strong a word, I was mostly just wrangling articles from writers and organizing stuff). Those were easy because we had a hard deadline: it doesn't make sense to release the 2006 anthology in 2008. Shortly after the first No Fluff, Just Stuff anthology was published, several people at ThoughtWorks (including Martin Fowler and Rebecca Parsons, the ThoughtWorks CTO) and I started talking about the possibility of a ThoughtWorks anthology. I don't mean to suggest that it was my idea; they were just talking to me about logistics. It was decided that Rebecca would edit it, and solicitations for articles went out. Lots of ThoughtWorkers expressed an interest (including me), and writing began.

But three problems manifested: first, no implied deadline existed, because this wasn't a dated book. Two, everyone working on and contributing to the book had day jobs, actually doing the stuff they were writing about in lots of cases. In addition to their day jobs, many were involved in open source projects: ThoughtWorkers contribute a lot to open source projects. And, third, ThoughtWorkers are notoriously ADD. Rebecca had the unenviable and well nigh impossible job of cat herding a bunch of ThoughtWorkers under the above constraints towards creating the anthology. And, of course, Rebecca is insanely busy as well. But, obviously, she made it happen. It took a while, but it's out now. It covers the gamut of things that interest ThoughtWorks, from project management to pretty hard core technical stuff, with some forward looking tidbits thrown in. The ThoughtWorks Anthology has essays by Roy Singham (the Roy of Roy's Social Experiment), Martin Fowler, Rebecca Parsons, me, Jeff Bay, Michael Robinson, Tiffany Lentz, Stelios Pantazopoulos, Ian Robinson, Erik Doernenburg, Julian Simpson, Dave Farley, Kristan Vingrys, and James Bull. The article titles give a glimpse of the range of information in this book: Solving the Business Software "Last Mile", One Lair and Twenty Ruby DSLs, The Lush Landscape of Languages, Polyglot Programming, Object Calisthenics, What Is an Iteration Manager Anyway?, Project Vital Signs, Consumer-Driven Contracts: A Service Evolution Pattern, Domain Annotations, Refactoring Ant Build Files, Single-Click Software Release, Agile vs. Waterfall Testing for Enterprise Web Apps, and Pragmatic Performance Testing.

Anthologies are currently all the rage. No only the No Fluff, Just Stuff ones, but O'Reilly's Beautiful Code (and a rumored upcoming one on architecture), and, of course, this one. Anthologies are nice because you can read them in little bursts. I think this one has both interesting stuff and does ThoughtWorks proud as a company. Kudos to all the writers and Rebecca for pulling it off. And don't ask her about a sequel, at least not yet: she needs time to heal.

RIA == Platform Play

2008-05-15T10:47:00.000-05:00

The shortness of the collective memory of the development world depresses me sometimes. Joel Spolsky has a great blog post from 2004 entitled How Microsoft Lost the API War. In it, he describes the real Microsoft crown jewel that lead to their domination of the personal computer: the Win32 API. If you were writing software in the mid-90's, you were writing it to the Win32 API. You might be using Visual BASIC, Delphi, PowerBuilder, Visual Objects (all 2 of it's users), FoxPro, dBASE for Windows (all 4 of it's users), etc. But you were writing desktop applications that ran on Windows. Then, Netscape came along and showed everyone that you could write software to open standards. Even though Microsoft eventually trampled Netscape, the damage was done: now you could write software that ran in browsers. Of course, Java had the whole "write once, run anywhere" mantra going, but building desktop applications in Java sucked then and it sucks now. Only a few companies have ever done it well (like JetBrains). Netscape's enduring legacy was that writing to standards (like HTML, CSS, eventually DHTML and JavaScript) was, while painful, possible. You can create rich applications where no one knows or cares in which language it's written.

Fast forward to today's development world. We're used to the pain required to write good web applications. We've got Ajax frameworks to smooth over the painful parts of JavaScript, people actually understand CSS, and you can build compelling applications on the web. Not an office suite, mind you, but pretty functional applications.

Which brings us around to the current hotness, Rich Internet Applications (RIA). Ever wonder why Adobe and Microsoft are slugging it out for that space? And Sun is running along behind with JavaFX saying "Wait, we want to fight too!". It's the new platform play. We've dealt with the pain of writing good looking web applications so long that when someone comes along and shows pretty pixels, we swoon. Yes, you can create beautiful applications using Silverlight and Flex. And Sun showed some awesome demos of JavaFX at JavaOne. But, if you write an application in one of those tools, you've bought a platform. You are no longer in a standards space. You can't take a Silverlight application and port it to Flex without a rewrite. Same goes with JavaFX. Whoever wins the RIA war has the new dominant web platform, just like Win32 back in the day. Sounds like a good reason for big companies to pour resources into the effort.

Of course, as my friend Mike Nygard pointed out during several expert panels, you pretty much buy into a platform play every time you start writing software. Yes, JEE is a standard across many application servers, but how many people are really careful to isolate the seductive goodies that come with your application server from the real JEE stuff? My guess is not many. So, you've kind of implicitly bought into a platform anyway. That's doubly true for .NET: yes, Mono exists, but more of a proof of concept than anything else.

Maybe this is OK. But I remember the reason to avoid single vendor platforms. One of the compelling reasons to move to Java when the JEE specs came out was the possibility of moving to another vendor, even with some strenuous effort. I can't tell you have many consulting clients I encountered in the mid-90's who had bought into a particular platform (say, Microsoft Transaction Server or ColdFusion) and were very productive with it...until they hit a real bug in the platform itself. I consulted at one company who had an 18 month project written to a proprietary platform when they encountered a show-stopping bug. They contacted the vendor who said "Yeah, that's a known bug. We're going to get a fix out for that in the next release, which should be in about 12 months". Even though it took them a long time, they scrapped what they written and started over, in Java. And you can bet they were careful about isolating the application server stuff from the specification.

Building to a single platform isn't necessarily a bad thing, as long as you go in with your eyes open. It's a trade-off: perhaps the pretty dancing pixels in Silverlight are worth the chance that you'll find something it doesn't support and end up with an application that doesn't quite do what your users want. But, beware of Dietlzer's Law: users want what they want, and are grumpy if you tell them "no". And, if you go with one of the RIA platforms, get ready to marginalize everyone without a PC. Some of these platforms have some support on mobile devices (and surely more to com, in a massive wave), but it's not going to be as good as plain old HTML for a long time.

If you are going to choose an RIA platform, please use it appropriately. Don't build forms in it: HTML is plenty good for data entry forms. I saw a demo recently of a text box that rippled when you touched it with a mouse or typed in it. Please. RIA is extraordinarily good for displaying information that is well nigh impossible in HTML and JavaScript. Use it for those kinds of visualizations. Most of the RIA platforms now don't support web metaphors like bookmarks, or addressable URL's. There's no reason to completely discard the parts of HTML that work well for which it is designed. Use HTML for general interactions, and use RIA for sophisticated visualizations. And know going in that you've bought a platform that you're going to have to live with for a long time.

A slightly different version of this rant, more Silverlight focused, appears here. I was at a party at a friends house that had lots of .NET folks there, during the Microsoft MVP Summit. I was getting some impending dead-line work done and Eric was recording a series of podcasts, the tone of which can be summed up by "Silverlight will cure cancer, solve world hunger, and paint your kitchen for you". After he was done, I was quietly fuming and asked him if he wanted a contrarian view. That's what's on the podcast. You've been warned!

RubyNation

2008-05-13T14:24:00.001-05:00

One of the interesting things that's happening in the Ruby community is the sprouting of regional conferences. Because Ruby is still nascent in the Enterprise space, it's hard to conduct conferences (especially regional ones like No Fluff, Just Stuff) because individuals probably have to pay for themselves (rather than having a corporation pay for them). This is a clear case of developers seeing the next thing they want to do, but companies lagging behind them. But Ruby (and Rails) has some pretty sophisticated stuff, which lends itself well to a conference. Thus, the rise of the regional conferences, many of them basically operating as a non-profit, trying just to cover expenses with the conference fees. And that describes RubyNation on August 1st & 2nd, where I'm delivering the opening keynote. It speaks highly of the Ruby community that the conference organizers are willing to put in a vast amount of effort (and believe me, putting on a conference is a huge undertaking) just for the love of the technology. That's a rare thing indeed, and shows what a wonderful place in general that the Ruby community is. I'm happy to speak at these regional conferences because I like the passion for technology on display. It's fun being around people who really care about technology, and love to debate it, discuss it, and generally wallow around in it (which is one of the reasons that I love ThoughtWorks so much). So, even if you have to get on a plane, come to Ruby Nation and wallow around with me. And, it that's no enough incentive, come because Stuart Halloway is making a relatively rare appearance as the closing keynoter. Should be a great couple of days.

Agile IT! Experience

2008-05-12T08:14:00.000-05:00

I'm speaking at the upcoming Agile IT! Experience, in Reston from June 26 through June 28. Most conferences focus on one attendee demographic: developers, business analysts, managers, CIO's (which entails much golfing and little conferencing). But projects must encompass a wide variety of roles, all of whom must work together. The upcoming Agile IT! conference breaks that mold. It caters to all members of the project ecosystem. That means that managers will rub elbows with developers, business analysts can chat with testers, and use the synergy of their experience to both understand how the other half lives and pick up valuable insights from other people that will make their work better.

I really like these kind of mixed conferences. Too often, conferences are too homogeneous. Getting a group of people together that have different perspectives always broadens the perspectives of everyone. This new conference blends several normally separate worlds, enriching all of them. I'm looking forward to IT!

Book Review: Programming Groovy

2008-04-29T08:59:00.001-05:00

In the movie 2001, A Space Odyssey, the director Stanley Kubrick spends a vast amount of time with lava lamp-style special effects. The last part of the movie is an interminable journey through the same scene with different colors. Kubrick would never make that movie now: at least a third would end up on the cutting room floor. But he was entranced with the shiny new technology and indulged it to distraction.

The same thing tends to happen when a new technology comes out. If you are an early adopter, you'll slog through the lava-lamp effects to get to the meat of the new technology. Groovy has followed this route. Because I've been following Groovy for a while, most of the previous Groovy books have been in two categories:

wow, look at this new thing! Isn't it cool that you can do all this stuff, which contains useful information but also a fair amount of "look, she's walking upside down for 10 minutes" kind of stuff

recipes for getting real work done (where Groovy Recipes falls, so I think it's very well named. I reviewed it just before this one.)

I don't mean for this list to sound pejorative: every new technology comes out with these books first: it's an inevitable part of the technology life-cycle for new languages. But eventually someone comes out with a book that no longer treats the new language like a shiny new thing, but as a serious contender in the language universe. And that's Programming Groovy by Venkat Subramaniam (disclaimer: I know Venkat, but you shouldn't hold that against him). It doesn't treat Groovy like a novelty act. It also doesn't provide recipes. Instead, it treats Groovy as a real programming language. I'll have to admit, this is the Groovy book for which I've been waiting.

Groovy is friendlier syntax for programming Java (I called it the real JDK here). Books about the practical aspects of Groovy are very important because, as a language, it resides in a unique place: it's a low impedance way to program the Java platform, and it displaces Java for lots of common tasks. But it is also a powerful language in its own right. Programming Groovy has 4 chapters on meta-programming Groovy, and another long chapter on building domain specific languages. That's meaty stuff. It never condescends or makes excuses for Groovy but treats it like a real language. It includes lots of material that's hard to find online (like how ExpandoMetaclass really works). This is going to be both a classic in the Groovy literature and an exemplar for describing the real power of new languages.

Book Review: Groovy Recipes

2008-04-27T18:51:00.001-05:00

While I've been "away", hammering away at my own book project (see this blog entry for that history), several important books have arrived that I haven't had a chance to talk about. I'll cover them in chronological order. The first is Groovy Recipes by Scott Davis. This is the Scott half of a book project that he and Venkat Subramaniam started a while ago as a single book (disclaimer: I know both authors quite well), and they quickly realized that they were writing separate books, so they made that a reality (I'll talk about Venkat's book in my next post). Groovy Recipes does what the title says: gives you recipes for how to get stuff done in Groovy. But that's only part of the value of this book. It also teaches how to become an idiomatic Groovy developer. And that's incredibly important. The classic book on C, the K&R book The C Programming Language, did 2 things for C. First and foremost, it taught developers about the c programming language. But the second more subtle thing it did was to teach developers how to be idiomatic C programmers. I can remember reading the book and marveling at the conciseness of the code, which had as much to do with the way the language was used as the language itself.

Anytime you learn a new language, you have 2 battles: first, learn the syntax (which is the easiest part -- it's just details of how familiar concepts are expressed in the new syntax). The second battle is the more important one: how to become an idiomatic programmer in that language. Developers new to a language tend to write new code just like code from their former language, using new syntax. Only when they've had time to steep in the better, more elegant ways of expressing yourself in a new language do they truly become proficient. That's what Groovy Recipes does for Groovy developers. It shows not just the syntax, but how to idiomatically use that syntax to become proficient with Groovy. Groovy is a much more powerful language than Java. While you can take a Java source file and rename it with a groovy extension and have it still work, you're writing Groovy code like a Java developer. After you've seen and used Groovy for a while, you start writing code like a Groovy developer. The Groovy Recipes book is two things: recipes for using Groovy to solve problems. But, more importantly, it teaches idiomatic Groovy programming, which is the long-term benefit of the book.

The Productive Programmer - History & Future

2008-04-25T06:58:00.001-05:00

No, I haven't fallen off the face of the earth. I haven't been blogging lately because I've been heads-down, finishing (finally!) The Productive Programmer. Understanding why it took so long requires some recent history.

Back in 2005, after having fully recovered from writing the Art of Java Web Development in 2003, I decided to look for a fresh book project. I started wondering if the world could use another book on Regular Expressions, other than the seminal work on the subject by O'Reilly. I asked a few people and the universal opinion was a resounding "No!": the current book is so good that it's pointless to try to write another. I was talking about it to David Bock, friend and No Fluff, Just Stuff colleague when I visited NovaJUG, the Java User's Group he facilitates in the DC area. He agreed with everyone else, and we started chatting about what we thought would make a good book. We had both recently observed developers struggling to make an IDE do something that was trivial on the command line, but the developers had spent their entire careers in graphical operating systems and IDE's, and couldn't bash their way out of a paper bag. We decided that it would be cool to write a book about command line tricks and techniques for developers, and that we would write said book. The original idea was to write a gigantic recipe book for programmer productivity. We contacted a publisher (who suggested the title The Productive Programmer), and we started gathering recipes and writing about them.

Then, 2 things happened. David left his job of many years and founded a consultancy, Code Sherpas, and instantly became 300% allocated. At about the same time, his wife Lorna became pregnant with triplets! Clearly, David now has his hands more than full. At about the same time, I realized that a book consisting solely of recipes would be the most boring book every written. But, by that time, I had also noticed some patterns in the productivity stuff in which I was now immersed. In fact, I remember the exact moment I realized that this book should show patterns (or principles) of productivity. I was in India, working on a ThoughtWorks project by day, and writing the book by night. I had some long conversations with some of the folks with which I was working (Hi, Mujir!) about this, and finally settled on the five principles of productivity (which later became 4). Instead of being a book of fish, I now had a fishing manual.

Of course, I've been busy as well, so the work on the book was intermittent at best. Plus the fact that the publisher was really expecting a recipe book, and it was no longer that. So, the publisher and I started going back and forth, wrestling over the format and content to try to mold it into something upon which we could agree. By this time, I had kind of taken over the book because David was so slammed. Eventually, I realized that no amount of massaging was going to create the book the publisher thought they wanted, so the publisher and I decided to part friends. I now had distilled the 5 principles down to 4 (I realized at some point that indirection is really just an aspect of canonicality) and written about them. While I was writing, I was also doing Productive Programmer talks at No Fluff, Just Stuff, honing the material that was perpetually going to be out RSN (Real Soon Now). I now had about 100 pages of refined material. But I also realized that the principles really only covered one aspect of developer productivity, the mechanical side. I also realized that I had been talking about the practical side of productivity in my older talk Clean Up Your Code and its modern sequel 10 Ways to Improve Your Code. That was the last piece. I contacted my now publisher O'Reilly with 1/2 of a productivity book and a clean vision for what the second half should be. So, from December until March this year, I wrote the 2nd half. And, fortunately, David agreed to write the forward of the book, which gave a pleasing resolution to the original vision we both had.

For all those long suffering attendees of my Productive Programmer talks at No Fluff, Just Stuff for the last 2 years: the book is ready. It's in copy editing now, and should be out soon. RSN. For real this time.

This is a thanks to all the people who've attended the talk over the last couple of years. Your questions and responses made the book better, and now you can hold one in your hands. And, now that I'm back from intensive writing, ready to reengage the blogsphere with a vengeance.

Rental Car IT

2008-02-18T09:43:00.000-05:00

I travel a lot. Mostly, when I travel and need a car, I get one through one of the major vendor's premiere customer program, meaning that I get to walk right to the car and drive away without much formality. Which is a good thing, because every once in a while, something is amiss and I have to go to the counter. And that entails dealing with rental car IT.

The amount of information you need to rent a car seems pretty small. Even if it's not, it's very well defined. You'd think that they would have the process honed; it is, after all, the primary thrust of their business. But watching the sheer number of keystrokes that the counter attendee must perform to put me in a car is astounding. The same is true when you bring it back. It's like they are typing the great American novel. What could possibly require so typing? They know who I am. They have all my credit card, insurance, and driver's license information (enough that they'll usually just let me get in a car and drive away). This isn't confined to a single rental car company either. I've dealt with a bunch of them and they all have an enormous amount of data entry.

Unlike a lot of problem domains in which I've specifically worked, I don't know for sure what's going on for rental car companies. But here's what I suspect: their IT infrastructure is strangling them. Ironically, many of the companies that embraced IT very early on (i.e., in the mainframe era) are suffering a lot now. Much of the interest in SOA derives from the desire to get out of the deadly embrace of fossilized, astoundingly brittle IT infrastructure.

Closer to home, I've recently been doing some consulting at a large company, helping them define their evolution towards a better tomorrow. I was talking to one of their senior IT staff, and I mentioned that it seems like they don't have a really good idea what their users need software for, and that maybe we should go talk to them. He looked at me like I had a new eye sprouting on my forehead, and said to me "We've tried talking to them -- they don't know what they want, so we have to define it for them. You can't be so naive to think that we can actually talk to the users." At this large enterprise, software is its own ecosystem. The users of the software almost never come up in meetings. Instead, it's a gigantic plumbing exercise. What's ironic is that this particular company is primarily run on information. Yet, they are so far down the rabbit hole of plumbing and complexity, they have managed to create mountains of rubbish. They are in the deadly embrace of accidental complexity, not essential complexity. My coworker and I identified their IT needs for the entire enterprise as small to medium, if this were a green field. But, of course, they have information trapped in mainframes, in several different formats of databases, in packaged applications, and scattered hither and fro, like lots of enterprises.

By way of trying to get them to rethink some of their decisions, we tried (and were marginally successful) in getting them to define some core principles, like simplicity and flexibility. What was funny about that exercise were the looks we got from the no nonsense King of IT: "Of course, we want things to be simple and flexible -- why are you bothering to tell us this?" Yet, in the next sentence, they are talking about spending 3 million dollars on a packaged application to help them with one small part of their business, rather than building it themselves (which we all thought would be cheaper but take longer). That's $3,000,000. But, of course, the packaged application talks directly to their databases, meaning that we can no longer freely make changes to the database without breaking the package, meaning that we can't evolve the database, meaning that we've lost both simplicity and flexibility. Over and over, they complain when we talk about rethinking their priorities, then turn around and make the same decisions that got them where they are now. Frustrating!

At another company I did consulting for years ago, they had a special mainframe application that handled one part of their business. I don't know how much it cost, but it had to be a lot because their vendor came to them one day and said "Look, we really just can't take any more money -- we're bloated and frankly we can't figure out how to spend all you've given us already." Instead of taking this opportunity to rethink how this part of their business works, the found another mainframe application that did the same basic thing, and spent 43 million dollars changing around the life support for this thing. Fundamentally, the problem they were solving wasn't that tough. I know; we were working on a piece of it and got a good feel for the whole thing. They were so drowning in the accidental complexity of the way they had always done it that they couldn't see the actual problem anymore. I walked into a conference room at one point, and saw a diagram that literally covered the entire wall with boxes, lines, and 8-point font describing the enterprise architecture (no, sorry, Enterprise Architecture). When one of the client developers walked in, I said "Wow, it's a good thing you guys dismantling this mess" to which he replied "No, that's the new one we're going towards". Decisions like this mean I have to spend my time in long lines in places like rental car counters.

Going back to first principles is hard, and many companies think it's too late. I've been involved on projects where getting back to a simple solution takes years. But it's worth doing. Otherwise, the company will drown in self-inflicted complexity, when IT becomes a governor on the business rather than a strategic advantage. When that happens, some other company with nimble IT will eat their lunch. Software can be either an asset or a liability.

Missing Family Member John Glasgow

2008-02-11T09:41:00.000-05:00

My wife Candy's cousin John Glasgow is missing. John was last seen leaving his Little Rock, AR home Monday morning around 5:30 am, January 28, 2008. A cell phone ping later that day indicated that he was in the vicinity of Petit Jean Mountain. His car was found unlocked the next day at the Mather lodge on Petit Jean with valuables still inside. He is believed to have been wearing a green Marmot down jacket and khaki pants at the time of his disappearance.

His family and friends are asking for help in locating John. We are hoping that someone out there will see John's picture and read his story and come forward with information that can help us find him. Distressingly, official search efforts were called off 2 weeks ago on Friday, even though the family has mounted their own search. Please go to www.findjohnglasgow.com to see a picture of John and print off a flyer. If you could put it in your car window or some other visible place, it would help us a lot. It is possible that he could have traveled out of the area where he went missing, so we are trying to get the word out on a national level, to cover all possible scenarios.

The Real JDK 2.0

2008-02-10T22:04:00.000-05:00

I always wondered what in the world the Sun marketing guys were thinking. They kept changing the real name of the JDK. Starting with JDK 1.2, they decided that they wanted to call it "Java 2", and the "Java 2 Platform". But developers still downloaded JDK 1.2. OK, that makes some sense, I guess. Then, when JDK 1.3 came out, it was still "Java 2 Platform". If there was any logic, it would now be the "Java 3 Platform". Well, OK, so now it's Java 2 forever. Then, when JDK 1.5 appeared, it became Java 5. Now they are clearly just making this stuff as they go. Now, the current thinking is that it's just the "Java Platform", and "Java Enterprise Edition" (to avoid the charming "JPEE" acronym). What in the world is going to have to happen for the real version number to trip up to 2.0. And why the reluctance? Is there something magical about version 2.0? Why didn't the marketing and technical guys just get together when JDK 1.2 came out and call it "Java 2" then? It's not like they're going to run out of numbers -- there are literally an infinite number of them!

Without realizing it, the technical guys didn't think (and apparently still don't) that Java was good enough for a real Version 2. They've been waiting...and now it's here. Groovy is the REAL Java 2. Henceforth, we can think of the Java language (not the platform) as forever 1.x. Groovy is what the real second version of Java should have been. The technical guys must have felt it their guts all along.

I've heard some rumors about wacky version numbers for Groovy. It leapt from 1.1 to 1.5. Stop it! When you make changes to it, increment the bloody first number! Unless you want someone in a decade writing a smarmy piece about how your technical marvel just got supplanted, and that it was a version 1.x technology all along.

aboutGroovy Podcast for 2G

2008-02-05T11:21:00.000-05:00

The 2G-Groovy/Grails Experience is just around the corner, and my buddy Scott Davis asked me to chat a bit about the talks I'm doing there ("Design Patterns" in Groovy, Groovyizing You Day Job, and Comparing JRuby and Groovy). That chat is now cast into pod, at this PodCast.

Polyglot Programming Parallels Perched Precariously per Patron Participation

2008-01-28T10:12:00.000-05:00

I just finished delivering my Software "Engineering" & Polyglot Programming keynote at the 2nd installment of CodeMash, and I got lots of great feedback from it. And it was the feedback that's useful, not the welcome but ultimately less than useful "I really loved your keynote". As I had hoped, some of the attendees took my remarks as a starting point and expanded upon what I said.

One good example of this is from Nick Watts. He sent me a long email, following up with blogged thoughts here and here. To summarize Nick's points, he noticed that many great writers will use phrases from other languages when the native language just won't do. I discussed this in a blog entry about Ruby syntax, but in this context it is more about polyglot programming than about Ruby. Nick notices it in Tolstoy's War and Peace, where the English translation leaves the French phrases alone. The first time I really took notice of the pervasive use of foreign phrases was in Nabakov's Lolita (which isn't translated, it was written in English), where the author uses so many French phrases that it distracted me at first. But then, I started looking up what the phrases meant, and it turns out that Nabakov was able to utilize phrases that just dripped with connotation with well placed French colloquialisms. "Joy of Life" as a translation for "Joie de Vivre" is a poor, hopelessly literal translation, missing all the rich connotations of that phrase. Another recent example popped up in the excellent book I'm reading called The Rest is Noise: Listening to the Twentieth Century by Alex Ross. He uses the phrase "Fin de siècle" over and over, but it carries much deeper meaning than just "end of the century", because it captures with it the connotations of what was happening then.

When I was an inexperienced reader, foreign phrases like this annoyed me, because I had to go look them up. Isn't English good enough? But as I've become a more experienced reader, I understand that some languages have phrases (colloquialisms) that are simply more expressive in very compact form. Translated to software, we are so accustomed now to writing in our "One True Language" that seeing other mixed in languages is off-putting. But, as we become more versed in polyglot programming, we'll see more opportunities to leverage appropriate colloquialisms in other programming languages to add to the expressiveness of our solutions without having to spell everything out in excruciating detail.

Thanks to Nick for not just listening to what I had to say, but listening to what I had to say. There is no greater reward for a speaker.

Talking Heads from CodeMash

2008-01-22T11:16:00.000-05:00

I got ambushed by someone with a video camera again, but it wasn't too painful. Just after my keynote at CodeMash, someone from Enerjy approached me and asked if he could film me chatting about some of the themes I suggested in my keynote. Well, it isn't hard to get me to talk about software, so he filmed some short segments. He also nabbed some of the other speakers and asked them similar questions, putting them together in themed video shorts. The first one is here: myself and my friend Andy Glover talking about the perpetual argument of art vs. science in programming.

Language Abstraction Layers

2008-01-17T18:01:00.000-05:00

Those who follow what I write and speak about realize that I return to several themes consistently: polyglot programming, domain specific languages, and dynamic languages. At some point, I thought I should tie those things together. And then someone did it for me better than I could have myself. My fellow ThoughtWorker, Ola Bini, writes brilliantly about the intersection of these topics in this blog post.

Ola is probably best known recently as one of the committers on the JRuby project. He's also a bigger language geek than me (no small feat). I think he correctly identifies the future abstraction stack in software: more strongly typed "verifiable" languages on the bottom (ironically implemented in looser typed languages like C for historical reasons), dynamic languages on top for getting real work done, and DSLs for abstractions on top of those to get us closer to the problem domain.

The Craptaculous Web Framework

2008-01-10T10:21:00.000-05:00

At No Fluff, Just Stuff, Sunday after lunch is reserved for the speaker's panel and poll. Jay polls the audience to find out what version of Java everyone is using, which Ajax libraries, IDEs, and that sort of stuff. One of the questions he always asks is "Which web frameworks are people using"? Generally, Struts still rules the numbers (although, recently, he's been asking how many people would use Struts on a new project and the numbers plummet). He rattles off the litany of web frameworks (there are dozens in the Java world, after all). And, on the panels I'm on, I pipe in by asking people how many are using their own, home grown "Craptaculous" framework. Interestingly enough, there are always hands. And the home grown Craptaculous framework generally beats out some well known rivals, like JSF (thank heavens) and Tapestry (what a shame).

This really shows the confusion in the Java world around about web frameworks. The only clear consensus is around Struts, and only because there are lots legacy projects that started with it. I put this down to the The Paradox of Choice, which Scott Davis references in his keynote No, I Won't Tell you Which Web Framework to Use (or, the Truth, with Jokes). Yes, there is an entire hour-long keynote about this topic. The Paradox of Choice shows that people's decision making capacity shuts down when presented with too many choices. The classic example from the book is the store selling jam. A little boutique store started presenting jam samples to entice customers. When they put out 3 different flavors, customers sampled them and the sales of jam soared. More must be better, right? So they put out 10 difference flavors...and the sales plummeted. When presented with too many choices, people's decision making ability shuts down.

Which I think it at play now in the Java web space. Scott's keynote is a direct result of this. Inevitably, at No Fluff, Just Stuff shows, the question comes up on the expert panel: "Which web framework should I use?" If there were only 3, you could reasonable go compare them. When the number reaches 10 or 20, there is no time to go sample each one. Thus, paralysis sets in and you end up using Struts (again), or creating another version of your home-grown Craptaculous framework.

For better or worse, other markets don't suffer from this. In the .NET world, there is only one: ASP.NET. But that is a different kind of market. Despite the efforts by many in the ALT.NET space, open source isn't nearly as prevalent in the .NET world as in others (I can't tell you how many clients I've talked to that created their own logging framework for .NET -- it just never occurred to them that this problem has already been solved over and over). In the Ruby world, there is really only Ruby on Rails (although there are others, they have a very small following compared to Rails). Same in the Python world: there are several frameworks, but as an outsider looking in, it seems that Django has all the buzz now.

Which suggests a clear new front runner in the Java world: Grails. Because it is based on Groovy, not Java, the perception is that it is the only game in town. That will help drive the adaptation of Groovy like wildfire. In fact, I think that Grails is the engine driving the interest in Groovy. New languages are cool and all, but until you have something to do with them, they don't catch on (look at what happened with Java when servlets came along).

Of course, I would be remiss not to mention that Rails now runs on the JVM via JRuby. However, I think this is perceived by many in the Java world as a bigger transition than Groovy and Grails. Ruby is a completely different language, with different idioms. To hard-core Java-ists, Groovy is practically Java, with most of the stinky parts removed. Once Grails becomes 1.0 and beyond, it may be salvation from the home-grown Craptaculous framework that Java developers are still using.

C# MVP & Polyglot Programmer

2008-01-02T13:46:00.000-05:00

I got the news today that I've been voted Microsoft C# MVP for the second year in a row. This may come as a surprise to people who only know me through my speaking at Java conferences, or think of me as a Ruby militant. But at heart, I'm a language geek. I love computer languages (it was after all my specialization in college) and I try not to get too religious about technology (to varying degrees of success because I also tend to get excited about technology). At my core, though, I'm a language switch hitter. I think it's important in this day and age of polyglot programming to understand a variety of different languages, as they are the design tools we use to craft software. Just like regular engineers must understand the physical properties of different materials, we should understand the capabilities, strengths, and weaknesses of different languages. And when to apply them.

Being a consultant affords me lots of opportunities to use different languages for different projects. The next project I move too is likely going to be a C# project. My last few have been (in order) Java, Ruby on Rails x 3, .NET x 2, and Java. I firmly believe that you should be versed in lots of languages because knowing multiple languages also exposes you to different idioms. I think that the classic K&R book ( The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie) was as much about the idioms of C programming as the language itself. And, of course, the Pragmatic Programmer admonishes developers to learn a new language every year. Dave Thomas has been very publicly learning Erlang over the last year or so (and taking lots of people with him). So, since it's new year's resolution time, what new language are you going to learn this year?

Creatively Common

2007-12-17T08:42:00.000-05:00

If you look closely at any of my presentations, you'll see the Creative Commons logo at the end. I'm using the "Attribution-Noncommercial-Share Alike" license, which means that you can use this presentation for whatever purposes you like as long as:

you say that it came from me originally
you don't make money directly from the work
you have at least as liberal license on your derived works (meaning that you have to share what you create as well)

For those not familiar with the Creative Commons, it's an alternative to copyright which gives consumers options. The problem with copyright law is that it is very restrictive, based on old models of interaction. It is in fact based on what Lawrence Lessig refers to as a "read-only" view of works. This makes sense before the technology we have today. Copyright prevents anyone from taking a book and going to the neighborhood Kinkos, making copies of it, and selling it as their own. And, it prevents anyone from taking a copyrighted presentation and saying that they created it. The problem with copyright is that it is binary: a work is either copyrighted or not (although I'm sure that intellectual property lawyers can haggle endlessly on the nuances of this). That means that I cannot allow people to base their derived work directly on mine through copyright.

Creative Commons is an attempt to create what Lessig calls a "read-write" culture, allowing specific rights for derived works. We live in much more of a mash-up kind of world. Musicians frequently use samples and other pieces of other music to create something genuinely new, not just a low-fidelity copy. The place where this is playing out in a fascinating way is in Japan, around manga (see the article entitled Japan, Ink in the November issue of Wired magazine). In Japan, there are well established serial manga stories (graphic novels) with original characters. But there is a huge market for derived works, where new (generally amateur) artists take the characters from a well known series and create new stories, frequently in directions that the original author wouldn't go (these are called dojinshi - non professional, self published manga). Imagine creating a Star Wars variant where Jar Jar Binks and C3PO ended up in a gay relationship. It is doubtful that you could sell many copies of this before a platoon of IP lawyers from LucusFilms were crawling up, well, you get the picture. Yet that's exactly what's happening with manga in Japan.

But, Japan's copyright law is about as strict as ours. Here's the interesting part: the publishers tacitly agree to allow this to continue. Why would they do this? The market for manga is huge and fickle. The dojinshi show them which series are waxing or waning in popularity. And, it provides a breeding ground for new authors. The very best of the dojinshi authors can become the next generation of legitimate manga authors. Because there is no structure in place in Japan, the publishers allow millions of dollars of dojinshi sales, with the looming threat of a lawsuit if they ever become too aggressive. The publishers are doing the smart thing: allowing a "read-write" culture which provides them lots of benefits: real-time market research based on actual sales, new authors, and a vibrant culture around their works.

Clearly, with the abilities created by digital media, copyright is going to have to change. I'm doing my part by allowing anyone to use my stuff with fewer encumbrances than copyright because I think this points to a new attitude about all kinds of intellectual property. For an eloquent presentation about this (and an incredible presentation for it's own right), check out this captured keynote by Lawrence Lessig.

The 2G Experience

2007-12-11T12:03:00.000-05:00

Is Groovy the future of Java? It may well be. The worst thing about Groovy these days is it's name. Want to terrify your boss? Go up to him and tell him you want to switch all your development to something called "Groovy". And don't let the door hit you in the ass on the way out. I'm lobbying the Groovy community to make a subtle name change, and it only applies when you are standing near some manager/adult. When they are around, always refer to Groovy as "The Enterprise Business Execution Language" (or even better, ebXl). That just sounds like something that a manager would go for (especially with that sexy capital "X" in the name -- what manager could resist?)

You too can have your chance to lobby the Groovy world at the upcoming 2G Experience, the first major North American Groovy/Grails conference. All the big names are going to be there, including folks from over the ocean. I'm going to be there as well, talking about Design Patterns in Groovy, Groovyizing Your Day Job (or how to start using it without frightening your boss), and a JRuby/Groovy Comparison, which should raise some hackles on both sides of the aisle. If you care at all about Groovy, this is the place to be in February.

ThoughtWorks DSL Podcast

2007-12-04T19:58:00.001-05:00

ThoughtWorks is starting an interesting experiment: because there are so many passionate people here, it spills over to the outside world a lot. The only problem is that it mostly just spills onto the people who are standing near ThoughtWorkers when they start talking passionately about subjects that only software geeks get passionate about. To control the spillover, ThoughtWorks has started a series of podcasts, combining subjects and those who love to talk about them. First out of the gate: myself, Martin Fowler, Rebecca Parsons (the ThoughtWorks CTO), and Jay Fields, in a 2-part podcast about Domain Specific Languages. Part 1 is now live.

Virtual Neighbors

2007-11-26T05:22:00.000-05:00

I was talking to my friend and fellow roaming-around-the-world speaker Jason Hunter a little while ago. He made the observation that the definition of distance has changed. He lives in San Francisco and I live in Atlanta. Yet, we see each other on a fairly regular basis. It's almost like we're neighbors, except that the common element is that we travel and work in similar places, not that we live next to one another. This is really true with guys like Scott Davis and Venkat Subramaniam, who I see about 1/2 the weekends of the year, always in a different city (driven by the No Fluff, Just Stuff schedule). I consider them my virtual neighbors. During the busy No Fluff, Just Stuff times, I see them a lot more (and more reliably) than my physical neighbors.

And it gets even more like living in the same physical neighborhood. The other day, I walked into the Red Carpet Club at O'Hare airport and heard someone call my name. Brian Sletten was waiting for a flight and we sat and chatted a while. What's funny is that Chicago is home for neither of us, and we were not in Chicago for the same reason. We both happened to be in Chicago at the same time. Just like you bump into your down the street neighbor at the hardware store, I bump into my virtual neighbors in random airports.

If you travel as much as I do, this is inevitable, I guess. As a company, ThoughtWorks travels a lot. I've bumped into co-workers in airports 2 different times when it was not the home city for either of us and we weren't going to the same place. The world is indeed smaller.

JRuby Podcast on JavaWorld

2007-11-21T22:34:00.000-05:00

My good friend Andy Glover interviewed me for a pod-cast for the Java World site recently, and it has magically appeared. Here is the site blurbage:

Neal Ford and Andrew Glover are both well respected Java developers, as well as big fans of Ruby. Neal FordIn this in-depth discussion, Ford talks about why he believes Ruby is the most powerful language you could be paid to program with today, and explains the particular benefits of programming with JRuby. Ford also reveals why he believes Java developers will continue to migrate to languages other than Java, even as many continue to call the Java platform home. This is an essential, engaging discussion for those interested in learning more about JRuby and the trend toward what Ford calls polyglot programming.

It was a lively conversation, and Andy asked me about lots of stuff I've been thinking about a lot lately. As in all good conversations, the time flew by, and before I knew it, the guy recording it was shutting us down.

Ruby Matters: Frameworks, DSLs, and Dietzler's Rule

2007-11-15T08:30:00.001-05:00

As an industry, we've been engaged in an experiment for the last decade or so. This experiment started back in the mid to late 90's, largely driven by the fact that the demand for software vastly outstripped the supply of those who could write it (this wasn't a new problem then -- we've had this problem almost since the idea of business software started). The goal: create tools and environments that would allow average and/or mediocre developers to be productive, regardless of the messy facts already known by people like Fred Brooks (see Mythical Man Month). The reasoning goes that if we create languages that keep people out trouble by restricting what damage they can do, we can produce software without having to pay those annoying software craftsman ridiculous amounts of money (and you'd probably never be able to find enough of them even then). This thinking gave us tools like dBASE, PowerBuilder, Clipper, and Access: the rise of the 4GL's.

But the problem was that you couldn't get enough done in those environments. They created what my colleague Terry Dietzler at the time called the "80-10-10 Rule" for Access: you can get 80% of what the customer wants in a remarkably short time. The next 10% of what they want is possible, but takes a lot of effort. The last 10% is flat out impossible because you can't get "underneath" all the tooling and frameworks. And users want 100% of what they want, so 4GLs gave way to general purpose languages (Visual BASIC, Java, Delphi, and eventually C#). Java and C# in particular were designed to make C++ easier and less error prone, so they built in some fairly serious restrictions, in the interest of keeping average developers out of trouble. The problem is that they created their own version of the "80-10-10 Rule", only this time the stuff you couldn't do was much more subtle. Because they are general purpose languages, you can get pretty much anything done...with enough effort. Java kept bumping into stuff that would be nice to do but was way to much work, so frameworks were built. And built. And built. Aspects were added. More frameworks were built. It is so bad that meta-frameworks were built: the Avalon framework was a framework for...building other frameworks!

We can see what this trend has done to productivity when building complex software. What we really want is the productivity of 4GLs with the generality and flexibility of powerful general purpose languages. Enter frameworks built with Domain Specific Languages, the current exemplar being Ruby on Rails. When writing a Rails application, you don't write that much "pure" Ruby code (and most of that is in models, for business rules). Mostly, you are writing code in the DSL part of Rails. That means that you get major bang for the buck:


  validates_presence_of :name, :sales_description, :logo_image_url 
  validates_numericality_of :account_balance 
  validates_uniqueness_of :name 
  validates_format_of :logo_image_url, 
                      :with => %r{\.(gif|jpg|png)}i,

You get a huge bunch of functionality with this little bit of code. 4GL levels of productivity, but with a critical difference. In a 4GL (and the current mainstream statically typed languages), it is cumbersome or impossible to do really power stuff (like meta-programming). In a DSL written on top of a super powerful language, you can drop one level of abstraction to the underlying language to get done whatever you need to get done.

This is the best approach currently available. The productivity comes from working close to the problem domain in the DSL; the power comes from the abstraction layer simmering just below the surface. Expressive DSLs on top of powerful languages will become the new standard. Frameworks will be written using DSLs, not on top of statically typed languages with restrictive syntax. Note that this isn't necessarily a dynamic language or even Ruby tirade: a strong potential exists for statically typed type-inference languages that have a suitable syntax to also take advantage of this style of programming. For an example of this, check out Jaskell and in particular the build DSL written on top of it called Neptune.

My Horse Scale of SOA

2007-11-10T23:10:00.001-05:00

I've been giving some SOA talks over the last few years, and I struggled for a while finding a good metaphor to describe the evolution from most people's existing enterprise architecture to the magical, mysterious enterprise architecture described in most of the marketing material around SOA. Then, on one of my talks, I stumbled upon it, and later created an image that sums it up: Neal's Horse Scale of SOA:

You see, the marketing literature describes something that doesn't exist in the real world: they are describing a unicorn. You've seen paintings, drawings, and movies featuring unicorns. If you came from another planet, you would assume that unicorns lived here because there are so many representations of them. The problem is that most company's enterprise architecture looks more like a broken-down donkey. The SOA experiment is to see how close you can get to a unicorn before you run out of money. Maybe you'll get to Shetland pony and stop. Or perhaps you'll make it all the way to a thoroughbred racehorse. There are even a few that'll create unicorns, but they are exceedingly rare.

The point is that you can't trust the magically vision marketed by pundits and (especially) vendors. Building unicorns is expensive, and the more donkeys you have around, the more it will cost. SOA isn't a zero-sum game. It's should be a spectrum towards improving the communication and interoperability between all your disparate equines (i.e., applications and services).

Language Spectrum

2007-11-06T21:48:00.000-05:00

It came up the other day in a conversation as to which programming language I would use absent the messy constraints like "Must make money to continue to eat". I think it would look something like this, from most preferred to least:

Ruby (I'm quite fortunate that I'm getting to use this language for money right now)

Lisp (I've never gotten paid to write Lisp, but would like to)

Smalltalk (note that I've never done "real" Smalltalk development, but I know about its cool features)

Groovy

JavaScript

Python

Scala

Java or C# (or any other mainstream statically typed language)

Interestingly enough, I think C# has the edge on language features (the new stuff they're adding for LINQ, and not doing stupid stuff like type erasure for generics) but the libraries are awful. Java the language is getting really crusty, but they have the best libraries and frameworks in the world (and the most of them too). If you could write C# code with Java libraries, you'd really have something. Of course, they are still statically typed, so you have to pay the static language productivity tax.

Haskell

O'Caml

Perl

Language_whose_name_I_cant_write_here_because_all_filters_in_the_world_will_block_it

Cobol (I've never done any real development here either, and don't plan to)

assembler

Jacquard Loom (whatever that language looks like)

Flipping switches for 0's and 1's

Universal Turing machine (infinite paper strip with a read/write head that moves forwards and backwards). It's just hard to find infinitely long paper strips these days.

Clearly, this represents my relatively recent evolution towards dynamically typed languages. They are simply much more productive if you assume that you write tests for everything, which I always do. Notably absent from the list is Delphi, which is so yesterday's news to me. It became deprecated as soon as C# grew all of its good features and left it behind.

This doesn't mean that I think that Ruby embodies the perfect language (haven't seen one of those yet). But, given the landscape, it feels pretty good, and I keep learning cool new stuff about it.

Building Bridges without Engineering

2007-11-01T21:56:00.000-05:00

One of the themes of my "Software Engineering" & Polyglot Programming keynote is the comparison between traditional engineering and "software" engineering. The genesis for this part of the talk came from the essay What is Software Design? by Jack Reeves from the C++ Journal in 1992 (reprinted here), a fissile meme that Glenn Vanderburg tossed into the middle of a newsgroup conversation about that very topic. Even though the essay is quite old, it is every bit as pertinent today as when it was written. The update that Glenn and I have given this topic is the addition of testing, which gives us professional tools for designing software. We don't have the kinds of mathematical approach that other engineering disciplines do. For example, we can't perform structural analysis on a class hierarchy to see how resilient to change it will be in a year. It could be because those types of approaches will just never exist for software: much of the ability for "regular" engineers to do analysis has to do with economies of scale. When you build the Golden Gate bridge, you have over one million rivets in it. You can bet that the civil engineers who designed it know the structural characteristics of those rivets. But there are a million identical parts, which allows you to ultimately treat them as a single derived value. If you tried to build a bridge like software, with a million unique parts, it would take you too long to do any kind of analysis on it because you can't take advantage of the scale.

Or it may just be that software will always resist traditional engineering kinds of analysis. We'll know in a few thousand years, when we've been building software as long as we've been building bridges. We're currently at the level in software where bridges builders were when they built a bridge, ran a heavy cart across it, and it collapsed. "Well, that wasn't a very good bridge. Let's try again". There was a massive attempt at component based development a few years ago, but it has largely fallen by the wayside for everything except simple cases like user interface components. The IBM San Francisco project tried to create business components and found (to the non-surprise of software developers everywhere) that you can't build generic business components because there are far too many nuances.

Manufacturing is the one advantage we have over traditional engineers. It is easy and cheap to manufacture software parts, by building the parts of software. So why not take advantage of that ability and manufacture our software parts in both the atomic, small pieces and then the larger interactive pieces and then test them to make sure they do what we think they do. It's called unit, functional, integration, and user acceptance testing. Testing is the engineering rigor of software development.

Here's the interesting part. If you told an engineer that you needed a large bridge and that you needed it so quickly that he doesn't have time to apply any of the best practices of bridge building (e.g., structural analysis), he would refuse. In fact, he would be liable for the bad things that would happen if he was foolish enough to proceed. We have none of that liability in the software world.

Responsible software developers test, just as responsible engineers use the tools of their trade to create robust, well designed artifacts. But we still have too much stuff that is untestable, along with pressure to write code that isn't tested because testing takes time. One of my litmus tests for deciding how to spend my time looking at new things (frameworks, languages, user interface approaches) is the question "is it testable?" If the answer is no (or even "not yet"), then I know that I needn't bother looking at it. It is professionally irresponsible to write code without tests, so I won't do it.

Impending QCon

2007-10-31T09:27:00.000-05:00

I'm speaking at QCon next week in San Francisco. Martin Fowler and I are pairing on an all day tutorial on Building Domain Specific Languages, a topic that he and I have much much interest. The tutorial takes an interesting format. The first part of the day will be a normal lecture/Q&A kind of affair. However, at some point in the afternoon, we're going to switch into workshop mode and actually build some DSLs based on suggestions from the audience. I think this is a great way to get people to not only understand what DSL's look like but get a bit dirty in designing some from scratch, working through the inevitable headaches that come up.

The other talk I'm giving is a "regular" presentation on Thursday about (you guessed it) Building DSLs. Looking forward to it.

What High Coupling hath Wrought

2007-10-28T21:57:00.000-05:00

A long time ago, I wrote a blog entry about the high price of coupling as it pertains to Internet Explorer and Windows. In it, I lambast Microsoft for the business decision to tie Internet Explorer so tightly into the underlying operating system. Developers all know that highly coupled systems are bad. And here's a stellar example.

Microsoft is finally going to release a "headless" version (called "server core") of their premiere server operating system (currently called Longhorn Server). Coincidental to this, they have built a new batch language for Windows called Windows Power Shell (nee Monad), which is simply brilliant. They have raised the bar on what a shell language can be. I can't heap enough praise on the coolness of WPS. What a great thing to have just as they are going to release a headless version of the OS.

Only one small problem. They want to make the footprint of the headless version of Windows Server smaller than the footprint of Vista (currently about 8 Gb, and that's just for the OS). The problem is that the headless version won't include .NET 2, because the .NET framework and libraries are coupled to just about every nook and cranny of Windows. If you include .NET 2, you pretty much include all of Windows. And there's the rub: Windows Power Shell is written on top of .NET 2. Which means that this brilliant tool for managing tasks, services, and general scripting of the operating system won't be available for the one system that could benefit from it the most.

I leave it to the reader to form their own conclusions.

Developer Productivity Mean vs. Median

2007-10-25T11:13:00.000-05:00


 10                                            .
  9                                          . .
  8                                      . . . .                                     
  7                                  . . . . . .
  6                              . . . . . . . .
  5                          . . . . . . . . . .
  4                      . . . . . . . . . . . .                         
  3                  . . . . . . . . . . . . . .             
  2              . . . . . . . . . . . . . . . .
  1          . . . . . . . . . . . . . . . . . .
  0      . . . . . . . . . . . . . . . . . . . .
        ___________________+_+___________________
         1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2
                           0 1 2 3 4 5 6 7 8 9 0

OK, first a little remedial math: mean is defined as the mathematical average of a series of numbers. For the set of numbers above, the mean = 4.55. The median is defined as is the number defined as lying at the midpoint of a sorted number series, which is 5.5 in this example.

Why in the world am I talking about this? Well, it pertains to developer skills. You see, really good developers are much more productive than average ones (this has been documented in several places, including the Mythical Man Month and Joel). In fact, some statistics say that really good developers are orders of magnitude better than poor ones.

Consider this version of the graph:


10                                            .
 9                                          . .
 8                                          . .                                     
 7                                          . .
 6                                        . . .
 5                                        . . .
 4                                        . . .                         
 3                                      . . . .             
 2                                  . . . . . .
 1                    . . . . . . . . . . . . .
 0            . . . . . . . . . . . . . . . . .
       ___________________+_+___________________
        5 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 1
          0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0
                                              0

For this one, the mean = 2.7 and the median = 2. If the height of the graph line represents programmer productivity, the second one is closer to reality.

So what does this mean to development? Managers used to think that this is a nice straight 45 degree angle, and that even if you can't get the best and brightest, you still get usefulness out of mediocre developers. But building software isn't like digging a ditch. Even poor ditch diggers can make a hole. In software, what you (and others) write today becomes the foundation for tomorrow. If you have bad developers building your foundation, the really good developers have to go back and fix it before they can build more useful stuff. Hiring mediocre developers (or just average ones) slows project velocity. Couple this with the fact that adding people to a late project makes it later, and you can understand why most enterprise development moves at a glacial pace. Building software in the large with lots of average developers emphasizes two negative project metrics: trying to scale by adding people and that average developers produce code on the average scale. But the truth is more like the lower graph: overall productivity is dragged down to the median level, not the mean level.

An entire industry has been built to solve this problem. It was thought that you can fix this problem in two ways. First, build restrictive languages that keep bad developers out of trouble. But, Glenn Vanderburg has a dead-on quote that reflects the reality that he (and I) have seen on projects: Bad developers will move heaven and earth to do the wrong thing. Command and control computer languages aren't like the governor on a car, forcing you to drive more slowly and thus more safely. At the end of the day, weak languages slow down your best developers and don't prevent the bad and mediocre ones from writing horrific code.

The other attempt at fixing this was to take restrictive languages and build really smart tools to help developers generate code faster. This is the classic implicit sales pitch for Visual Basic: no one can hurt themselves, and you can hire cheaper developers to write your code, without paying a good salary to those annoying software craftsmen. It is widely known that Microsoft internally calls mediocre developers "Morts" and targets them with some of their tools. Of course, this doesn't apply to all Visual Basic developers and not to good developers in the .NET space. But it is the reality that this dual strategy is the way vendors have sold tools for the last couple of decades.

And now we see that it doesn't work. Part of the ascension of dynamic languages is the realization that the experiment of command and control languages don't make average developer's code any better, and it hampers your really good developers. Why not figure out a way to unleash the good developers and let them go as fast as they can? Ruby on Rails is a good example of using domain specific languages to create a simpler language on top of Ruby for things like ActiveRecord relationships. For everyday coding, you can stay at the high, simple abstraction layer. If you really need it, you can dip below that abstraction level and get real work done in Ruby. For many of the Ruby projects on which I've been involved, using open classes is done strategically, accounting for between 1.5% and 4% of the total lines of code. Yet that surgical use of one of the kinds of meta-programming that Ruby allows eliminates hundreds of lines of code.

So what does all this mean? First, give good developers powerful tools and you'll get higher quality software faster. Second, as an industry we would become more productive if 30% of the existing developers were laid off tomorrow. Having warm bodies doesn't help projects, and having to baby-sit poor developers cuts the productivity of your good developers. Software is too complex to turn into an assembly line manufacturing process, at least for now. Good software developers are still craftsmen, no matter how much that annoys companies that wish that wasn't true.

Ruby Matters: Unleash the Brainiacs!

2007-10-21T07:23:00.000-05:00

ThoughtWorks was early in the game in the Java world. Lots of the standard parts of the Java stack (like CruiseControl, Selenium, etc.) were built by clever ThoughtWorkers from project work (there is a long list here). Working with smart, passionate people who have damn good ideas, coupled with the corporate culture that nurtures open source, is one of the advantages of working at ThoughtWorks.

Fast forward a decade, and the same thing is playing out again. Lots of ThoughtWorkers really like Ruby. And one of the things that I suspected early on was that the combination of ThoughtWorkers and a super powerful language would be a good mix. And I was right.

As we've been doing Ruby projects, ThoughtWorkers have been generating great ideas like mad. Because Ruby is such a rich language, really smart people build really cool things. And, of course, ThoughtWorks likes to open source stuff, which is a good combination. The Ruby part of this equation means that you can build stuff that, while sometimes possible in other languages, is too much trouble, so you just don't do it. Imagine that you were traveling to Chicago a decade ago, and you wondered about the weather forecast. How would you find it? You could call the hotel and trust that someone there knows it. Or you could watch the weather channel and wait for the Chicago forecast to come on. Or you could go to the library and find a Chicago newspaper and look there. All of these were so much trouble that you were likely just to skip it and guess. Now, you can find out in about 10 seconds by using the Internet. Convenience opens possibilities.

Here is a perfect example. Jay Fields, Dan Manges, and David Vollbracht has released a Ruby gem called dust, which makes it easy to do write better test names (and other stuff). Or what about deeptest, which allows you to run unit tests in parallel, written by Manges, Vollbracht, and anonymous z. Or what about Mixology. This is a gem created by Pat Farley, anonymous z, Dan Manges, and Clint Bishop in the Something Nimble crowd that allows you to dynamically change mixins. If you aren't sure what that means, think about the ability to change what interfaces a class implements at runtime, based on some criteria. Not just add new ones, but remove them as well. While not something you do everyday, it does come up and there are good uses for this capability.

As ThoughtWorkers are building Ruby projects, we're helping spawn lots of cool infrastructure (like CruiseControl.rb). Of course, ThoughtWorkers aren't the only ones. But you get a bunch of smart people together combined with a powerful language and good stuff happens.

Check out Something Nimble, a blog maintained by ThoughtWorkers working on Ruby projects, spawning cool stuff left and right.

Mocking JRuby

2007-10-17T17:04:00.000-05:00

Testing is one of the easy ways to sneak JRuby into your organization because it is easier to write tests in dynamic languages (especially mock object tests) and it isn't code that is deployed, so it eases the minds of the furniture police somewhat. Here is an example, adapted from Martin Fowler's essay on mock object testing.

In Martin's example, he creates Order and Warehouse classes (and a Warehouse interface), then writes tests with them in jMock. Here is one of those tests, rewritten in JRuby, using the Mocha mocking library:


  require 'test/unit'
  require 'rubygems'
  require 'mocha'

  require "java"
  require "Warehouse.jar"
  ['OrderImpl', 'Order', 'Warehouse', 'WarehouseImpl'].each { |f| 
    eval "#{f} = com.nealford.conf.jmock.warehouse.#{f}" 
  }


  class OrderInteractionTest < Test::Unit::TestCase
    TALISKER = "Talisker"

    def test_filling_removes_inventory_if_in_stock
      order = OrderImpl.new(TALISKER, 50)
      warehouse = Warehouse.new
      warehouse.stubs(:hasInventory).with(TALISKER, 50).returns(true)
      warehouse.stubs(:remove).with(TALISKER, 50)

      order.fill(warehouse)
      assert order.is_filled
    end

    def test_filling_does_not_remove_if_not_enough_in_stock
      order = OrderImpl.new(TALISKER, 51)
      warehouse = Warehouse.new
      warehouse.stubs(:hasInventory).returns(false)
      order.fill(warehouse)

      assert  !order.is_filled
    end

  end

The order object is a pure Java object, tested with a mocked out version of the Warehouse interface. Now, this isn't exactly what Martin wrote in in excellent essay about mocks vs. stubs, but the intent is preserved in this example.

Most of the really crufty stuff in mock objects in Java is getting the compiler to agree with you that the mock object type is what you want it to be, and of course that problem goes away in JRuby. Also notice that I can create the mock object directly off the interface. Because JRuby creates proxy objects for the Java classes, you can create a mock from the interface directly by calling the new method on it. The other cool thing about this example is the require "Warehouse.jar" line at the top. JRuby allows you to require a JAR file, which gives you access to the Java classes within it.

Ruby Matters: Contracts vs. Promises

2007-10-13T07:38:00.000-05:00

In teaching Ruby to Java developers, two things seem to shock and annoy developers: open classes and the lack of interfaces. Because Java developers are inundated with interfaces, it's hard to imagine a language whose libraries are strictly defined in this manner.

Interfaces in Java and .NET are exactly like legal contracts (where the compiler is the all-powerful judge). If you implement an interface yet don't meet the terms of the contract, the judge refuses to allow you to proceed.

Mixins in Ruby are more like promises than contracts. When you agree to pick up a friend at the airport, you don't sign a contract, you promise you'll be there. The punishment is purely social: if you break a promise, your friends won't do stuff for you. Here's an example.

In Ruby, a common Mixin is Comparable, which gives you the same behaviors as the Comparator interface in Java. The promise in Comparable is that you will implement the "spaceship" operator (<=>), which returns negative if the left-hand side is less than the right, 0 if they are equal, and positive if the LHS is greater than the RHS (which is exactly like the similar compare() method in Java).


 class Employee
   include Comparable

   attr_accessor :name, :salary

   def initialize(name, salary)
     @name, @salary = name, salary
   end

   def <=>(other)
      name <=> other.name   
   end
 end

 list = Array.new
 list << Employee.new("Monty", 10000)
 list << Employee.new("Homer", 50000)
 list << Employee.new("Bart", 5000)

 list.sort!
 # Monty vs. Homer
 list[0] < list[1]       # => true

 # Homer vs. Monty
 list[0] > list[1]       # => false

 # Homer is between Bart and Monty?
 list[1].between?(list[0], list[2])    # => true

If you violate the promise by mixing in Comparable and yet don't implement the spaceship, nothing bad happens...until you try to ask your friend Comparable to perform a service for you (like compare two things with between? or call the sort! method). Then, you get an error message complaining "undefined method `<=>' for Employee". And this happens at runtime, not at compile time.

This is a fundamentally different mindset than the legalistic strongly contracted languages. It demonstrates one of the reasons that you can't slack off on writing your unit tests in Ruby: you don't find out important things until runtime. It is certainly a different way of thinking about implementing APIs. While lots of Java developers think this leads to chaos in large development teams, I have not found that to be true (and I think that most Ruby developers would agree with my assessment). The trade-off is strict control vs. flexibility. If there is one thing that my experience has taught, it is that flexibility is the most important thing for strong programmers, echoed by many of Paul Graham's essays.

If you must have stronger contracts in Ruby, there is a framework called Handshake that allows you to create pre- and post-conditional invariants ala Eiffel. While I understand the appeal of Handshake, I would be loathe to use it on a project because I prefer the power of flexibility rather than the strictures of constraints.

Ruby Matters: Language Beauty Part 2

2007-10-08T12:32:00.000-05:00

A dead chrysanthemum
and yet - isn't there still something
remaining in it?
Takahama, Kyoshi

Let me not to the marriage of true minds
Admit impediments. Love is not love
Which alters when it alteration finds,
Or bends with the remover to remove:
O no! it is an ever-fixed mark
That looks on tempests and is never shaken;
It is the star to every wandering bark,
Whose worth's unknown, although his height be taken.
Love's not Time's fool, though rosy lips and cheeks
Within his bending sickle's compass come:
Love alters not with his brief hours and weeks,
But bears it out even to the edge of doom.
If this be error and upon me proved,
I never writ, nor no man ever loved.
William Shakespeare

Can computer languages be beautiful? Is it possible to create a beautiful COBOL application? I think it is possible, but you can't compare different languages as if they all had the same constraints. For me, these comparisons are like comparing poetry styles. Within a particular poetry style, you can clearly have beauty. But some poetry styles have serious constraints. For example, a Haiku has exactly seventeen syllables, in three lines of five, seven, and five. A sonnet is a poem with fourteen lines, using any formal rhyming scheme, having 10 syllables per line. Shakespeare wrote some stunning poetry within these pretty serious restrictions!

Computer languages are closer to poetry than prose. The syntax of the language imposes order, just as the conventions of different poetry styles constrain what you can create. Within those constrains, though, you can create wonderful things. But the strictures of the poetry style necessarily prevent you from creating more ambitious works. William Faulkner famously said that he wanted to be a poet and failed, then he wanted to be a short story writer and failed, and eventually became a novelist because he couldn't say what he wanted to say within the boundaries of the other styles.

A lot of developers who find themselves "at home" in a particular language can relate to this. For many developers, Java (the sonnet) feels just right. Yes, there are restrictions, but they are well known and seem right. Other developers chafe at the imposed limitations and seek more expressive media, like Perl or Ruby. And if it was just about aesthetics, we could all live happily, each developer writing code in whatever medium he or she liked.

But with computer languages, expressiveness == power. Being able to say what you mean succinctly and effectively matters. The only reader who you must satisfy completely is the execution environment. Thus, when making a language choice, it makes sense to pick the most powerful language you can stand. Of course, different developers rate power differently. For me, meta-programming is extremely valuable. It's one of those features that, once you've used a language that supports it extensively, it's hard to go back to a weaker one.

Which brings me around to Paul Graham again. When I first read Hackers and Painters, I remember thinking that about 80% of what he said was dead on, and the other 20% was either just crazy or intentionally inflammatory. Over the last few years, though, as I've learned more about languages myself, I go back to his writings (most of which are online at paulgraham.com) and realize that he's exactly right about something I used to disagree with him about. Now, I'm down to thinking only 5% is crazy or inflammatory, and that number is shrinking all the time. Anyway, one of those things was his language power scale, which I discounted at first but now believe to be an outstanding yardstick by which to measure language power.

For me, Ruby has a great combination of succinct expressiveness and super powerful meta-programming support. I think that it is currently the most powerful language you can get paid to write. Until Smalltalk makes a come back or Lisp eventually takes over the world, it's the best game in town. But that doesn't mean that I can't still write sonnets in Java and C# from time to time, when the circumstances warrant.

Ruby Matters: Language Beauty Part 1

2007-10-04T08:26:00.000-05:00

Beauty without expression is boring.

Ralph Waldo Emerson

I was talking to a colleague (named Vivek) recently who is originally from India. He was telling me about "Hin-glish", the merging of English an Hindi. I am already familiar with "Singlish", the flavor of English tinged with Malay, Hindi, Chinese, and several other languages spoken in Singapore. Vivek was telling me that it is quite common when talking to someone else who knows both English and Hindi to freely flow back and forth between the languages. That got me to thinking about expressiveness in language. We do this all the time in English without specific foreign influences: we use phrases like "Joie de Vivre" and "Cul de sac" all the time. Expressions in other languages just make more sense; some languages have found a useful, concise label for common human experiences and other languages don't bother creating their own term for it. Phrases like this encompass much more than the literal translation. They manage to encapsulate tons of connotation, not just the denotation of the meaning of the words. (For a supreme distinction between connotation and denotation (and none too shabby language either), check out this Robert Graves poem The Naked and the Nude).

Expressiveness of language makes a big difference. Having concise, nuanced representations of common concepts means less context establishment. This is one of the compelling arguments for domain specific languages: if you encapsulate high-level meaning in code, you spend less time talking about it. This is the vocabulary that describes your business, and everyone talks the same language so that you don't have to start from scratch every time.

Talking about beauty in programming languages sounds silly, because they are after all just ways to drive Turing machines. But people still talk about it. O'Reilly has a popular recent book named "Beautiful Code", which has essays by famous programmers. Reading this book clearly indicates that this opinion is purely subjective. My friend Brian made a great observation about this book: the essays written about other people's code really do illustrate beautiful code, while the ones written by developers about their own code are mostly about cool hacks. Most of those examples I would not consider beautiful by any measure, even if clearly highly functional.

Glenn Vanderburg has a great talk entitled "The Beauty of Ruby", discussing the elegant language design entailed in Ruby. For example, it is necessary in object-oriented languages to distinguish member variables from local variables. Java does this either via scope (which can be ambiguous) or the this keyword. Python does this with self (which is required in some places). Ruby uses the @ symbol. It is unobtrusive, unambiguous, and small. And it conveys exactly the meaning you need it to convey without being too chatty. Similarly, class-level artifacts in Ruby are identified with two @ symbols.

For me, Ruby does in fact have beautiful syntax. It is easy to write, easy to read, just succinct enough to keep you from typing too much but not so succinct to become cryptic. Many Perl developers think that Perl is beautiful (and, Perl was after all developed by a linguist). But I think it goes too far, bordering on cryptic (and I'm not the only one: many people refer to Perl as a "write only" language because it is so hard to read later).

Interestingly enough, even when I was primarily using Java, I never considered it beautiful. Utilitarian, but lacking beauty. But most of the post-Java developers I know still talk about the beauty and elegance of Ruby. I've never heard those phrases so much about other languages.

Language beauty will always be subjective. I explore this idea further in part two of this topic, coming up soon.

Travel: Biking Adventures Through the Woods Outside Frankfurt

2007-09-22T13:31:00.000-05:00

Warning: this post is entirely about travel stuff: there is no software or technology here, so feel free to avoid this if that's all you care about.
Terry Dietzler and I have spoken at the Entwickler conference for 9 years in a row (that's how I always spend my last week of September). On the first trip here, the hotel had bicycles you could borrow for the day, and we did several bike trips through the German countryside (the conference is in a suburb of Frankfurt, named Morfelden, near a national forest). We were hooked. Biking in Europe is a blast: there are bike routes simply everywhere (you can buy maps of just bike routes in bike stores). Our most elaborate trip to date was in 2003, when we biked about 200 miles in 2 days, from Frankfurt (actually, Morfelden) to Metz, France. In 2002, we made a deal with the conference organizer: in lieu of payment for pre-conference tutorials, buy us bikes and keep them in Frankfurt for us, in the basement of their offices. They kindly agreed, so Terry and I have bikes that live year-round in Germany.

This is all prelude to the adventure we had yesterday (we tend to have lots of adventures when we are here in Germany). We took the train (the S-bahn, or regional train) into the city and picked up the bikes. We had thought about bringing them back to Morfelden on the train, but decided instead of ride them back: follow the Main river trail until it gets out of the city, them find our way back to Morfelden. The biggest problem: the Frankfurt airport is between us and Morfelden, but we had maps, so we can find our way. Here is the route we ended up taking (Terry has a GPS, and he turned it on, so we got a record of the entire route):

It was 9 miles (according to the GPS) from where we picked up the bikes to our destination...as the crow flies. We estimated more like 20 miles because of the major obstacle, the airport. About 2 hours should to it; we started out at about 5.

As you can tell, we made good progress along the river, and we got minorly lost a few times as we lost the trail then reacquired it later. Very typical. Then, as we got near the airport, we started having to cross more major autobahns and train tracks. There are abundant bike bridges and crossing, you just have to find them. And, notice the backtracking as we neared the airport. We got on one trail that literally dead-ended at the junction of two sets of train tracks. As we're thrashing around, the sun is setting. Many of the trails are through the woods, so it's getting darker and darker. Our bikes have headlights, but mine was the only one working. So, picture this: we're biking through dense woods in pitch blackness following one headlight. Fortunately, the trails are very good, but it was still spooky and hard to do because the light only reached a little ways ahead of us, and it looked like we were biking into a black wall, which made me claustrophobic.

Fortunately, we've biked around Morfelden a lot, and as we got close, we recognized a landmark from a former trip. We followed the trail through a really dark and increasingly cold section of trail until, to the right, we spotted our hotel. 4 hours after we started, we ended up cycling 23 miles (including all the switch backs). What fun; we're going out again tomorrow.

Ruby Matters: "Design Patterns" in Dynamic Languages

2007-09-10T22:39:00.000-05:00

As I mentioned in my last post (Ruby Matters: Meta-programming, Synthesis, and Generation), the Gang of Four design patterns book should have been named "Palliatives for C++". One of the authors finally admitted as much in public at a roast. So, why would design patterns be any different in a dynamic language (like Smalltalk or Ruby)?

In the GoF book, design patterns are 2 things: nomenclature and recipes. The nomenclature part is useful. It's a way of cutting down on repetition of similar code across projects, and it gives developers a way to talk to one another, using shorthand. Instead of saying "I need to create an object that can only be instantiated once", you say "singleton" (we'll leave aside for the moment why Singleton is evil -- the subject of another blog entry). Nomenclature good.

But the fatal flaw in the GoF book was that they included recipes. And many people thought they were the best part. Even now, you see books on Java design patterns that blindly mimic the structure of the examples in the GoF book (even though Java has some better mechanisms, like interfaces vs. pure virtual classes). Recipes bad. Because they suggest more than just a way to name common things. They imply (and put in you face) implementation details.

Because of meta-programming, many of the design patterns in the GoF book (especially the structural ones) have much simpler, cleaner implementations. Yet if you come from a weaker language, your first impulse is to implement solutions just as you would from the recipe.

Here's an example. Let's say you have a simple Employee class, with a few fields (which could be properties in the Java sense, but it makes no difference for this example).


  public class Employee {
      public String name;
      public int hireYear;
      public double salary;

      public Employee(String name, int hireYear, double salary) {
          this.name = name;
          this.hireYear = hireYear;
          this.salary = salary;
      }
      
      public String getName() { return this.name; }
      public int getHireYear() { return this.hireYear; }
      public double getSalary() { return this.salary; }
  }

Now, you need to be able to sort employees by any one of their fields. This is a flavor of the Strategy Design Pattern: extracting an algorithm into separate classes so that you can have different flavors. Java already includes the basic mechanism for this, the Comparator interface. So, here's what the code to be able to compare on any field looks like in Java:


  public class EmployeeSorter {
      private String _selectionCriteria;

      public EmployeeSorter(String selectionCriteria) {
          _selectionCriteria = selectionCriteria;
      }

      public void sort(List<Employee> employees) {
          Collections.sort(employees, getComparatorFor(_selectionCriteria));
      }

      public Comparator<Employee> getComparatorFor(String field) {
          if (field.equals("name"))
              return new Comparator<Employee>() {
                  public int compare(Employee p1, Employee p2) {
                      return p1.name.compareTo(p2.name);
                  }
              };
          else if (field.equals("hireYear"))
              return new Comparator<Employee>() {
                  public int compare(Employee p1, Employee p2) {
                      return p1.hireYear - p2.hireYear;
                  }
              };
          else if (field.equals("salary")) {
              return new Comparator<Employee>() {
                  public int compare(Employee p1, Employee p2) {
                      return (int) (p1.salary - p2.salary);
                  }
              };
          }
          return null;
      }
  }

You might protest that this is overly complicated, and that this will do the job:


  public Comparator<Employee> getComparatorFor(final String field) {
      return new Comparator<Employee>() {
          public int compare(Employee p1, Employee p2) {
              if (field.equals("name"))
                  return p1.name.compareTo(p2.name);
              else if (field.equals("hireYear"))
                  return p1.hireYear - p2.hireYear;
              else if (field.equals("salary"))
                  return (int) (p1.salary - p2.salary);
              else
                // return what? everything is a legal value!
          }
          
      }
  }

but this one won't work because you must have a return, and returning any value is mis-leading (every possible integer here means something: 1 for greater than, 0 for equal, -1 for less than). So, you are left with the bigger version. I've actually attempted to optimize this several ways (with more generics, reflection, etc. but I always get defeated by the requirement to return a meaningful int from the comparison method. You could find some kind of minor optimization, but you are still building structure to solve the problem: a class per comparison strategy. This is the typical structural approach to solving this problem.

Here's the same solution in Ruby, using a similar Employee class:


  class Array
    def sort_by_attribute(sym)
       sort {|x,y| x.send(sym) <=> y.send(sym) }
    end
  end

In this code, I'm taking advantage of several Ruby features. First, I'm applying this to the Array class, not a separate ComparatorFactory. Open classes allow me to add methods to built-in collections. Then, I'm taking advantage of the fact that Ruby method calling semantics are message based. A method call in Ruby is basically just sending a message to an object. So, when you see x.send(sym), if sym has a value of age, we're calling x.age, which is Ruby's version of the accessor for that property. I'm also taking advantage of the Ruby "spaceship" operator, which does the same thing that the Java compare method does: return a negative if the left argument is less than the right argument, 0 if they are equal, and positive otherwise. Wow, it's nice to have that as an operator. I should add that to Java...oh, wait, I can't. No operator overloading.

Perhaps it makes you squeamish to add this method to the Array class (open classes seem to terrify Java developers a lot). Instead, in Ruby, you could add this method to a particular instance of array:


  employees  = []
  def employees.sort_by_attribute(sym)
    sort {|x, y| x.send(sym) <=> y.send(sym)}
  end

Now, the improved employees array (and only this instance of array) has the new method. A place to put your stuff, indeed.

When you have a powerful enough language, many of the design patterns melt away into just a few lines of code. The patterns themselves are still useful as nomenclature, but not as implementation details. And that's the real value. Unfortunately, the implementation seems to be the focus for many developers. Strong languages show you that the implementation details can be so trivial that you hardly even need the nomenclature (but its still useful as a conversation shortener.)

Next, I'll talk about language beauty.

Ruby Matters: Meta-programming, Synthesis, and Generation

2007-09-05T19:06:00.000-05:00

In my last Ruby Matters blog post, I talked about meta-programming in Ruby, contending that Ruby gives you "places to put your stuff". I always wondered about meta-programming in Smalltalk and how that compares to Ruby, and Where to Put Stuff in Smalltalk. The final piece of the puzzle came after I talked to Glenn Vanderburg (the Chief Scientist of Relevance). I was puzzled as to why the Gang of Four book (which had examples in both C++ and Smalltalk) didn't have more meta-programming. Lots of the design patterns are almost trivially easy to implement with meta-programming, but they didn't do that in the Smalltalk examples. They used the same structural approach as C++. It looks more and more to me that the Design Patterns book was really just a way to solve problems in C++ that should have been easier to solve in a more powerful language like Smalltalk. Which is why I was puzzled about the lack of of more meta-programming solutions in Smalltalk. Glenn enlightened me. One of the overriding characteristics of Smalltalk is the way code is stored, in an image file, which allows for really smart tools. The program and the environment all reside in the binary image file. There are no source files as we know them today, just the image.

A comparison about implementation details is in order, on how Ruby differs from Smalltalk. Let's talk about has_many in Ruby on Rails. Typical Rails code looks like this:


class Order < ActiveRecord::Base
  has_many :lineitems
end

For those not familiar with Ruby, this is a method, defined as a class-level initializer (just like an instance code block in Java, a chunk of curly-brace code in the middle of a class definition, which Java picks up and executes as the class is instantiated). So, ultimately, this is the Ruby equivalent of a static method call, which gets called as the class is created.

Let's talk about Smalltalk, which has first-class meta-programming. You could easily build has_many in Smalltalk, implemented as a button you click in the browser which launches a dialog with properties that allow you to set all the characteristics embodied in the Ruby version. When you are done with the dialog, it would go do exactly what Ruby does in Rails: generate a bunch of methods, add them to the class (stuff like the find_* and count_* methods). When you are done, all the methods would be there, as instance methods of your class.

OK, so at this point, the behavior is the same in Smalltalk as in Rails. But there is one key difference: The Smalltalk version using code generation. It's a sophisticated version of a code wizard, generating the code using meta-programming techniques. The Ruby version uses code synthesis: it generates the code at runtime, not build time. Building stuff at runtime means more flexibility. But that is a minor point compared to this one: In the Smalltalk version, you use the dialog and properties to generate all the methods you need. The original impetus for the has_many intent lives only while you are running the dialog. Once you are finished, you are left with lots of imperative code. In the Ruby version, the intent stays right where you put it. When you read the class again, 6 months from now, you can clearly see that you still mean has_many. Smalltalk has the same meta-programming support, but the intent of code synthesis remains forever. That's why it's important to have a place to put your stuff. It isn't accidental in Rails that many of the DSL characteristics appear as class methods rather than code you call in the initialize method. Placing them as part of the class declaration declares intent in a big way, and keeps the code very declarative.

To summarize the similarities and differences:

Both Ruby and Smalltalk give you a place to put your meta-programmed stuff

Both give you a place to put the declaration of intent (the tool in Smalltalk, the shadow meta-class in Ruby)

A time in the lifecycle of the class when things happen. In the Smalltalk version, it's a one-time deal, as you use the tool to generate the code. In Ruby, the synthesis takes place at class load time. This leaves the clean, declarative code right where you put it, rather than generating a bunch of much less clear imperative code.

Glenn made an excellent point here: the Smalltalk version is a great example of accidental complexity, not essential complexity. Software is full of essential complexity: writing software is hard. But we end up subjecting ourselves to lots of accidental complexity in our tools and languages. And it should be stamped out. The Ruby version eliminates accidental complexity by providing a great abbreviation for the intent of has_many. This blog does a great job of illustrating the differences between abbreviations and abstractions.

Smalltalk had (and has) an awesome environment, including incredible tool support. Because the tool is pervasive (literally part of the project itself), Smalltalkers generally shied away from the kind of meta-programming described above because you have to build tool support along with the meta-programmed code. This is a conscious trade off. One of the best things about the Ruby world (up until now) is the lack of tool support, meaning that the tools never constrained (either literally or influentially) what you can do. Fortunately, this level of power in Ruby is pretty ingrained (look at Rails for lots of examples), so even when the tools finally come out, they need to support the incredible things you can do in Ruby.

Next up, "design patterns" in Ruby.

Thanks to Glenn for supplying me Smalltalk information, as a sounding board for this, and all the interesting bits, really.

Ruby Matters: A Place to Put Your Stuff

2007-09-03T16:34:00.001-05:00

Why are so many people into Ruby? I get this question a lot because I speak at a lot of Java conferences and talk about Ruby and JRuby. In this and several more blog entries, I'm going to explore this question in depth.

For myself and many of my peers, it was a rite of passage to learn all the intricate tricky stuff in C++. Once I got over my fascination with C++ and got tired of banging my head against all of the arcane nonsense in the language (I used to know the details of all the different ways you could use the word const, but I've fortunately purged that knowledge), I asked one of my colleagues why he continued to love it so much. "Knowing C++ makes me part of the C++ priesthood. When people ask me questions, I'm purposely cagey when I give them answers because I think they should work as hard as I did to figure this stuff out. I don't want to give my advantage away." I shuddered and was glad I wandered to greener pastures.

After a brief visit to the refugee camp of Delphi, I made it to Java and thought I was in heaven. Finally, a language that made some sense. I liked the locked down nature of the language because I thought that Java helped prevent mistakes, especially for large projects. This is before I had embraced unit testing, so that seemed like a good thing. I would gladly give up flexibility for perceived safety. This was when I used to think that one of the most important duties of a computer language was to prevent mistakes first and support building interesting stuff second. Interesting stuff must be hazardous to large projects, and I was an Enterprise Developer. After more than a decade in Java, I started playing with Ruby because I'm a bit of a language geek and I was taking the advice in The Pragmatic Programer to learn a new language every year. But, at the time, Ruby was just a cool little scripting language with nice syntax.

When Ruby on Rails came out, I started looking at it with great interest because it was so vastly different from the Java frameworks with which I was so familiar (this was just after I had written a book comparing them). And the more I looked at Ruby, the more puzzled I got. Wow, there's some funky stuff in there, and I couldn't understand what some of the code meant. So, I dug deeper. And slowly, I gained enlightenment. At first, I thought that it was just more of the same "obfuscated code" syndrome from C++. But I later understood that it wasn't.

The epiphany really came when I understood what some of the Rails code was doing with meta-programming, which made me look closer at the core Ruby stuff. Meta-programming was supposed to be scary stuff that only wild hackers did. But it made problems melt away, in very few lines of code. If you look at how attr_accessor works, it's so simple. I thought for a long time that attr_accessor was a keyword or something infra-structural that I shouldn't bother looking at (before I realized that lots of stuff in Ruby looks like keywords but they aren't).

I have come to understand that meta-programability is an extremely important part of a language. So many things that we solve in languages like Java with complex structures and hierarchies are much more elegantly solved with meta-programming. This realization led me to start looking around at other languages, like Smalltalk and Python.

That's when it hit me: one of the things that makes Ruby so powerful is that it already gives you a place to put your stuff. If you don't think this is any different than Java, check out whytheluckystiff's Seeing Meta-classes Clearly article. I'll wait... Yes, there is a shadow meta-class behind every object in Ruby, giving you the syntax and location to put much of the interesting meta-programming stuff in Ruby. You can do lots of the same meta stuff in, for example, Groovy, but you have to create a Groovy builder object to do the equivalent of eval. And, doing class_eval would take more building a place to put it. I was talking to a Python programmer recently, talking about the same subject, and I got the same response: "Yeah, Python can handle that, but you'll have to build a place to put it." One of the elegant features of Ruby is that it comes pre-defined with places to put your important stuff, rather than forcing you to build a place to put your stuff. Which is why Paul Graham says that Lisp is the most powerful language available; because you are writing code in the abstract syntax tree, you are living in the place where stuff gets put.

In the next post, I'll talk about the special case of Smalltalk, tools, and code generation vs. synthesis.

Martin and Me and DSLs

2007-08-24T20:08:00.000-05:00

Back in June of this year, Martin Fowler and I did a keynote at The ServerSide Symposium in Barcelona on a subject for which we both have some interest (and dare I say passion): Building Domain Specific Languages. I saw cameras at the back of the room, but it didn't actually dawn on me that they were filming the whole thing...and that they would put in on the web. But, sure enough, here it is. It took them two months to post it and I think I know why: some poor person had to go and transcribe Martin and me yammering away for an hour. I hope they got paid well!

This keynote pretty much summarizes much of the thinking that I've been doing about DSLs over the past couple of years, and it is nice to see the agreements and disagreements that Martin and I have on some nuances of this topic. Clearly, though, we both think this remains a Big Deal.

Lights, Cameras, Geeks!

2007-08-20T22:24:00.000-05:00

At the Agile 2007 conference this year, they asked for submissions for videos featuring agile development themes call the Agile Advert contest. ThoughtWorks submitted a couple (created in ThoughtWorks UK) and won the top prizes. You can see them on YouTube under Developer Abuse and Being Agile is our favourite thing. Hilarious!

Pair Programming Spellchecking

2007-08-08T19:58:00.000-05:00

My colleague Jay Fields has a nice post about pair programming, when it's good, and when it's not so good. I wanted to add to and amplify his remarks a bit. Basically, anytime you pair two developers of vastly different skill sets (what Jay calls a "spell checking pair"), that's not pair programming: it is mentoring. That doesn't mean that it is wasted time, but it is a different activity.

I find that mentoring is tiring for both the advanced and novice developers: tiring for the advanced developer because they have to go slower than their natural pace and tiring for the novice because they are having to peddle faster to keep up. However, mentoring is a great way to greatly increase the skill level of the novice. If you are going to mentor, it should be for just part of a day. After the mentoring is done, switch pairs with more matched levels.

A lot of companies seem to think that's what pair programming is: take a intern from college and pair them with an ace to build up their skill level. All that does is stress both.

We are generally careful when engaging with clients to pair program with their developers to determine if the project is enablement or delivery. If it is delivery focused, we tell them that the more senior developer may well leave their pair in the dust, and should be reorganized. You can't usually do both enablement and delivery at the same time except in rare circumstances.

Dependency Injection in One Sentence

2007-08-06T15:30:00.000-05:00

Jim Weirich issued a challenge to describe dependency injection in once sentence. My friends at Relevance had a good version. Here's mine:

Dependency Injection enables a vitally important but nevertheless weak, limited, syntactically confounding, and dauntingly complex form of one of the kinds of meta-programming that should exist in the language.

This is fun -- can we do annotations(C#)/attributes(Java) next?

No Fluff, Just Stuff eXchange: London 2007

2007-08-06T15:08:00.000-05:00

Way back in the late nineties, I was working for The DSW Group, which was a Borland partner. We did Borland training classes worldwide, and that's ultimately how I got into the business of speaking at conferences. At the time, I was all geeked up about Delphi and at the first few BorCons I spoke exclusively about it and C++ (in the form of C++Builder). However, in the late 90s, I stopped having that lovin' feeling for Delphi and started really dedicating my efforts in the rising tide of Java. But what was interesting to me was the adoption level in different countries. I was still traveling to BorCons around the world, talking about JBuilder. And some countries I would have huge audiences. And in others, you could see tumbleweeds blowing through the aisles. I remember the first few Java talks I did at the Entwickler Conference in Frankfurt, no one even knew what "Java" was.

It was interesting because the UK seemed to be one of the last holdouts for Java. Even into the early 2000s, I would go to Borland conferences in London and be in the small room, while the Delphi groups were packed. Of course, these were Borland conferences, so the crowds were self selecting, but it seemed to me like Java was a slow burn in the UK. Then, of course, overnight, it was the cool thing to do.

London is now a first-class Java city, with lots of Java work going on (Java is very popular in the financial sectors, and London sure has lots of that). The only thing missing from the London Java scene finally appears this August: No Fluff, Just Stuff. What better place to make the cross-ocean debut of the premiere Java conference. In the past, people have literally flown from the UK and mainland Europe to see No Fluff, Just Stuff shows in the US, in random cities like Columbus, OH. Now, you can ride the tube to see a No Fluff, Just Stuff show!

The traveling circus that is No Fluff, Just Stuff invades London on August 29th, for 3 days. It's the normal cast of speakers from the US (including Venkat Subramaniam, Ted Neward, Brian Sletten, David Geary, and I've managed to stow away as well) mixed with some great guys from the UK (my ThoughtWorks colleague Erik Doernenburg, Graeme Rocher of Groovy/Grails fame, and some wild cards).

To help pump up the enthusiasm for this event, No Fluff, Just Stuff and Skills Matter have a cool promotion. Every attendee who registers before August 17th with the special code of NFJS-NEF666 will receive a Nintendo Wii. Not "entered into a drawing for a Wii" -- "will receive a Wii". Wow.

Come see us in London -- it should be a blast.

Polyglot Programming at erubycon

2007-07-11T10:03:00.000-05:00

In less than a week, I'll be doing a special version of my Polyglot Programming keynote at erubycon in Columbus, OH. In it, I talk about how to make Ruby palatable to conservative enterprises, and some arguments against "conventional wisdom".

If you are into Enterprise Ruby, there are still slots available at this conference. This conference will have a great combination of speakers who are actively pushing Ruby and Rails into the Enterprise. Lots of us see bright futures for dynamic languages and their potential in traditional IT; come see a bunch of like minded speakers (and attendees) who are on the cutting edge of making it happen.

The Rich Web Experience

2007-07-08T09:16:00.001-05:00

The web is changing. Just a couple of years ago, we had reconciled ourselves to treating the browsers as a graphical dumb terminal. Ajax and related technologies have changed all that. And anytime there are seismic changes in the technology landscape, developers have to learn the whole new world. The preferred way to do this quickly is to attend a highly focused conference.

That's what The Rich Web Experience is all about: rich application development that running in the browser. This conference is beyond just a single technology's APIs. It also covers security, usability, and other topics. I'm speaking on testing and debugging the web tier, including a bunch of best practices with Selenium.

Come join us in San Jose for what should be a rocking good gathering of cool web based technologies.

Travel Broadens You

2007-07-07T10:16:00.000-05:00

Not too long ago, I was in India to speak at JAX India. The conference was held at a science center in downtown Bangalore, and the speakers were staying in a hotel several miles away. One of the interesting things about India is that you can hire car services for cheap, so the conference organizers had a platoon of cars at our disposal, for trips to and from the conference center, which took about 20 minutes (it would be about 5 minutes if there was no traffic, but apparently that state never exists in Bangalore).

While driving to the conference center a couple of times, we passed a part of town where there were several cows lounging in the road, in amongst the traffic. No one even noticed: the traffic flowed right around them as if they were any old standard barrier in the road. Of course, it struck me as very odd, because I almost never see cows on the main roads of Atlanta.

It made me realize that people can get used to and habituate anything. During the conference, I talked to Java developers about some of the odd things in Java. Java has its share of strange behaviors (generics, anonymous inner class syntax, the recursive Enum definition) that look to strangers as odd as a cow standing in the road. Because Java developers are accustomed to seeing these cows all the time, they don't even notice anymore. But it strikes tourists as very odd and surprising.

Here is a concrete example. Groovy makes it really easy to interact with Java objects, including those that follow the standard JavaBean specification for get and set methods to form properties. In Groovy, when you create a new class, you can create your properties using the get and set style of coding, yet when you call the property, you can leave the get and set off.


class Foo {
  def name

    def getName() {
        return name.toUpperCase()
    }           

    def setName(value) {
        name = value
    }
}

foo = new Foo()
foo.name = "Homer"
println foo.name

Now, when I refer to what looks like a regular public field (to a tourist), I get the uppercase version because of the automatic mapping to a getter. To a Java developer, this auto-magic mapping from the property methods to actual properties seems as normal as can be. However, to a Java tourist, it looks as strange as a cow in the road.

This suggests 2 things to me. While every language has its own bizarre quirks, it is the seemingly irrational stuff that turns off tourists to the language. Do you really want to go into a history of the JavaBean specification to the poor Python programmer who's vacationing in JavaLand so that they can understand this weird but expected behavior? And will they possibly stay awake for it? Probably not, so they'll just say something like "Wow, Java's broken" and move on. I think this hampers attempts to expand Groovy's meme outside the Java world. I know there are efforts to port Groovy to the .NET platform, but will it possibly attract any .NET developers because of its unabashed Java-ness?

The other thing this suggests to me is the advice in The Pragmatic Programmer to learn a new language every year. Just as physical travel broadens you, traveling to a strange language broadens you too, so that when you see cows in the road back home, you understand that it's not normal for everyone. Stranger in a strange language, anyone?

Fair and Balance Essays?

2007-07-05T16:50:00.000-05:00

An interesting review of the 2007 No Fluff, Just Stuff Anthology appeared on Amazon the other day. Generally, I don't bother to reply to Amazon reviews (because it is after all someone's opinion, and I can't dispute someone's else's opinion), but this one has some interesting points. First and foremost, I would like to thank the reviewer for giving us 4 out of 5 stars, so his complaints should be kept in perspective (he did at the end of the day enjoy the book, and I don't want to gloss over that by way of indicating that we don't appreciate that immensely).

The reviewer mostly takes me to task for not forcing the authors to be more balanced against what he calls "agitation for the new age software movement". If you look closely at the cover of the book, you'll notice I'm not listed as the editor, but as the compiler (as in "Compiled by Neal Ford"). This distinction is important and planned. I did not edit this book in the normal sense (of vetting what the authors want to write), I merely compiled the essays. Frankly, it would be an awful job trying to get this group of authors to bend to my will! All the authors of this anthology are quite passionate about their subjects (which is what makes the book interesting, in my opinion).

The reviewer takes Brian to task for not providing the WS-* case against REST, but I don't think that was the purpose of the essay. Where in the vast ocean of information about WS-* do you even see a mention of REST? Unless you are specifically comparing two technologies, you frequently don't, well, compare them. I notice that David Geary (whose excellent essay was praised by the reviewer) didn't compare and contrast it with Struts, which is the de-facto market leader.

But the more interesting issue for me is the clear disdain the reviewer has for what he calls "new age dogma": REST vs. SOAP, dynamic languages, and Agile development. It's no secret that many of the No Fluff, Just Stuff speakers do prefer agile development and looser contracts. While not suitable for all applications, this is the cutting edge of software development right now. It is contingent on "thought leaders" to point out the latest trends in software development, so that the attendees and readers know what's on the horizon. Software and software development continues to evolve at a furious pace. While no one can predict the future (except maybe Bruce Tate), it is interesting to see where the people who were really into Java in 1996 are spending their time now (a hint: mostly with loose contracty type stuff).

Oh, and the reason there is more information about IntelliJ than Eclipse? Because most of the authors use IntelliJ (because we think it's the best tool available), I got inundated with cool IntelliJ tips and tricks (and ended up cutting a bunch of them). We had to ask over and over to even get tips for Eclipse, which is not to say that Eclipse is bad, it just doesn't generate as much passion than IntelliJ. There's that word again: passion. All the writers of this volume are passionate about technology (which is extraordinary in and of itself), and want to write about it for very little remuneration.

Given the amount of other open source in the book, why wouldn't we prefer Eclipse over IntelliJ it they were essentially the same? As a group, we tend to choose things that we think are best of breed, whether web framework or IDE. Hopefully, that's at least some of the appeal of both the anthology and the No Fluff, Just Stuff tour.

PragMactic-OSXer

2007-07-02T10:07:00.000-05:00

New Mac OS X users are like recently reformed smokers: they can't stand to see it when someone indulges in their old vice (in this case, Windows). I made the total plunge about 1 1/2 years ago, and more and more of my friends are doing it too. People who attend No Fluff, Just Stuff often note that most of the speakers are using Macs: the answer I frequently give is "because we can". It is crystal clear to me that I am simply more productive on the combination of Mac hardware and Mac OS X. I'm paid for how much I can produce in a given amount of time, so it makes sense for me (even if I have to buy it myself) to pick the sharpest tool I can find.

However, just picking up a Mac won't instantly make you more productive. In fact, if you just scratch the surface, you have no idea that Mac OS X is a deep ocean. There is always a learning curve when you switch something as important as an operating system. To that end, several of the No Fluff, Just Stuff speakers and myself have started a blog devoted to making the best use of the Mac. It is called "PragMactic-OSXer". If you are switching, or are just curious to see how the other half lives, come over for a visit (or attach your blog reader to it.)

TSS DSL Keynote Recap

2007-06-28T14:56:00.000-05:00

Martin Fowler and I just finished delivering the keynote on Language-Oriented Programming at The ServerSide Symposium in Barcelona, Spain. He and I have never presented together before, but we are both passionate about this subject, so it sounded like fun. And it was. I created a skeleton slide show in Keynote, to which he added and made suggestions, and we paired for about 1/2 hour the night before to make sure that it represented not only a consensus view but also good leaping off points for the presentation. We approached it like a public conversation: we had pretty minimal slides, and we took turns talking about the subject (along with minor disagreements) along the way.

There was a little bit of a frenzy just before it started. For some reason, some projector switching boxes just don't seem to like the Mac. My laptop worked fine in all the other breakout rooms (that only had one projector). In the main room, my machine could see that it was attached to an external monitor (I could see the resolution, the refresh rate, and every other detail about the external projectors), but for some reason they refused to show the image. I worked on this with an increasingly frantic IT guy from the hotel. We tried a Dell laptop and it worked fine. He kept insisting that there was something wrong with my machine, and I kept demonstrating to him that I could see his equipment just fine. I've encountered this problem before (see this entry, and it always turns out to be the switching box for the projectors, which for some bizarre reason has an affinity for Windows). Finally, as a last resort (time was running out), I exported the presentation from Keynote to a PDF file, copied it to a thumb drive, and moved it to the Windows laptop. I lost all the animations and other effects, but the slides looked OK. By this time, it was time to start speaking, so I opened the slide show full screen on the laptop. Unbeknownst to me, someone had set the machine to operate in kiosk mode when Acrobat is full screen, so the slide show starting playing without me doing anything. Finally, rather than try to figure out how to turn that off in front of 300 people, I just left it with the Acrobat Reader border showing and launched into the talk. As much as I love the Mac, it seems that the rest of the world still harbors ill-will for anything non-Windows. And it's not major stuff anymore -- it's the strange little things like switching boxes for projectors.

For anyone who saw the presentation, that was why it was in non-full screen Acrobat Reader view. Despite this hiccough, I thought the talk went reasonably well. Martin and I both have lots to say on this topic. When we started, I feared that we wouldn't have enough material, but he and I are both prodigious talkers, so we ended up having to rush a little to get to the end. I feel like we presented a pretty good summary view of how we both feel about this important subject.

Speaking at TSS Barcelona Next Week

2007-06-23T08:25:00.001-05:00

I spoke at the The ServerSide Symposium in Las Vegas earlier this year. Next week, I'm traveling to Barcelona (for the first time) to speak at the European edition. Martin Fowler and I are pairing on the keynote, about Domain Specific Languages (a topic for which he and I share considerable enthusiasm). I'm also doing a regular talk on Selenium.