Ben Scofield

I’m generally a pretty calm guy. We’ve all got pet peeves, though, and one of my occurs all too frequently. I’m talking about people who think their decisions and mistakes while driving are irreversible. You know, people who cut across three lanes of traffic to make a left turn into a mall parking lot, when they could easily make a u-turn at the next light – that sort of thing. In the grand scheme of things it’s clearly trivial, but it never fails to tick me off.

I discovered the Myers-Briggs personality inventory nearly fifteen years ago (I’m an INTP, thanks for asking), and one of the dimensions it evaluates is very much related to the idea that decisions are irreversible. People range from perceiving to judging (I know, they’re pretty awful names for the trait, but go with it) – where perceivers typically put off making a decision, and judgers tend to prefer having things settled.

I mentioned I’m an INTP, where the P stands for perceiver. Given the above brief description, then, you might expect me to be on the side of the irreversible-deciders, but in fact reversibility makes being a perceiver much easier. What better way to decide what to do could there be than actually making a provisional decision and seeing what happens? This has parallels in all sorts of fields: minimum viable products, agile development, tasting while cooking – they’re all predicated on committing to a course of action as little as possible, and being able to adjust (or even reverse) that commitment as necessary.

I think we’d all be a lot happier if we realized that relatively little in life is irreversible – and who knows what you may discover by trying something out without the fear of having committed to the wrong course forever.

I just read a post from Micah Baldwin that I found very interesting, so here’s a quick response:

Failure is bad.

Success is good.

Sure, failure can teach you valuable lessons – but so can success, and success has the added benefit of being success.

What the “failure is good” mentality misses is that failure is good only as a means to future success. Micah’s friend did exactly the right thing: he used his past failures to guide him to the choice that he perceives has a greater potential for success. In my book, that merits much more than a, “Fair enough.” Anything else would be actively courting failure – mistaking the process for the goal, and forgetting the lessons of follow-through.

I’ve given my “Comics” Is Hard talk about five times now, and the feedback consistently fell into one of two buckets:

• Some people wanted to see more of the domain modeling part, either because they still weren’t convinced that comics, etc., are hard to model relationally, or they enjoyed seeing me get riled up.
• Other people wanted to see more of the alternative database part. Generally, these people already knew that some domains were hard to model, or they had other needs that were pushing them towards a NoSQL solution and they wanted more background and examples.

Given that feedback, I finally bit the bullet and split the talk into two, each of which will hopefully please one audience. RubyConf was the first time I’ve given either of these, and I’m thinking that NoSQL: Death to Relational Databases(?) was a success.

First, the slides:

I think the slides from this talk are more capable of standing alone than many of my more recent decks, so I won’t go into much detail here. Basically, I spoke about five reasons people are looking at NoSQL solutions now, described four major families (key-value stores, column- and document-oriented databases, and graph databases), showed how those families generally stack up for the aforementioned reasons, and gave a quick example of how to use one or two systems from each family (e.g., Redis, Cassandra, MongoDB, Neo4J), all before wrapping up by describing several scenarios that might demand hybrid solutions.

I tried a couple of different things in this talk. I’ve looked at integrating the backchannel before (taking questions over Twitter, etc.), but with the conference wifi in a pretty bad state that wasn’t possible. I’ve also been thinking about ways to keep the backchannel going after the talk itself, which Twitter, IRC, and the like can’t handle. To that end, I’ve set up a Google Wave for the talk – if you’d like to join in the discussion, try this link (if it doesn’t work, you can search on ‘with:public NoSQL Death to Relational Databases’ and it should pop up).

I also decided to provide a few explicit next steps for the audience. Much too often, speakers leave their goals – what they want the audience to do as a result of their talk – implicit, expecting the audience to pick it up by osmosis and be instantly motivated to do it. Unfortunately, that never really happens, so I went ahead and stated my goals outright.

I got some great face-to-face feedback after the talk, and I was very happy with how it went. SpeakerRate hasn’t been as uniformly positive, however, and I’m afraid that the wifi situation prevented a number of people who attended from rating and/or leaving a comment – at the moment, I’ve only got nine ratings, when the room was mostly full. All in all, though, I’m encouraged by the talk, and I’m looking forward to giving it again (updated, of course) at CodeMash in January.

Twitter’s lists are a fascinating new feature, and people are using them in a bewildering variety of ways. I think one of the most unexpected effects they’ve had, though, has been the exposure of yet another problem with Apple’s App Store approval process: it’s just not agile enough.

Say I was selling a Twitter client on the App Store. In an ideal world (read: the web), the primary bottleneck to delivering a new version of the product is the development time – Twitter releases lists, I burn the midnight oil a bit to incorporate them into my app, and I’m done.

When you’re developing for the iPhone, however, the main bottleneck isn’t the development time, but the approval process. Every update to the core functionality of the application has go through the approval queue just like a new application, which means that it can be weeks or months before it gets onto your customers’ phones. (Or never, as has been the case with a recently rejected app update.)

Similarly, entirely new applications face the same problem. Fred Wilson just posted a Twitter list-powered application idea, but there’s no way a native app could be released to the public quickly to take advantage of it.

This has always been something of a problem for desktop development, of course – particularly before online patch distribution – but the iPhone has taken it to new heights. Web clients were able to add support for lists as quickly as they could push their developers, but native applications are left to lose their audience until Apple deigns to approve their updates. I’m surprised that the effect isn’t greater, actually, since the web-based Twitter clients should be promoting the heck out of mobile-optimized views of their sites with list functionality. Scoble‘s favored way of interacting with Twitter is a web-based client, in part because of its list support (see the last paragraph).

This is just one more problem with the App Store approval process, but it has the potential to be one of the most serious. As more and more mobile applications rely on web services for their functionality, the mismatch in time-to-market between the moderated App Store market and the quick-as-you-can web ecosystem will cause more (and more serious) problems.

In case you didn’t notice, the CFP for RailsConf 2010 in Baltimore went out yesterday – and along with it, the news that I’m co-chairing the conference with Chad Fowler. I’m very excited to be a part of the team this year, and I’m really looking forward to helping shape the conference.

If you’ve got ideas for how RailsConf could be the very best it can be, I’m all ears! Feel free to leave a comment here, or email me.