At the Fifth International Ruby
Conference, like others I sat engrossed by Nathaniel
Talbott’s talk on the "long tail" of software development.
There we were, an audience full of geeks who like to write code, hearing
how our favorite technology (Ruby) was enabling geeks who like to write
code to make money doing so. It was an exciting and tempting idea.
Nathaniel talked about his wife’s co-op’s Excel spreadsheets,
and how many small (often local) organizations across the country have
similar, ineffective spreadsheets. There’s money to be made in
writing small, focused applications to cater to the very specific needs of
these little groups, says Nathaniel. And according to the bigger ongoing
"long tail" discussion on the ‘net, there is an opportunity
to provide previously underserved fringe groups with a product that will
delight them like no general-purpose product has or can.
Tempting, as I said. And true sometimes, I would guess. But…
Sam Ruby, who was also at
the conference, picked
the long tail presentation as a favorite. But while the conference
brought up a lot of discussion of Naked
Objects in Ruby and various RAD tools, I think Sam hit on something
more relevant that a lot of us are likely to miss:
Those are the long tailer developers of today. Nathaniel asks: what happens when t approaches zero? Nathaniel's answer was that people who aren't currently developers wont suddenly want to become ones even if the cost were essentially zero. IMHO, the answer is that you will see a lot more applications like that financial application that was written in Excel.
It’s not just about who will be doing this development.
It’s about why. Hint: These people aren’t going to be
developing apps themselves because it’s cheaper than before.
We developers are quick to dismiss the little Excel and Access applications
that "lusers" tend to write. We assume that they would do them in
a "better" technology if only they knew how. But they
don’t, so they either have to wait around for a software developer to
come around and save the day, or they have to settle for this ugly
Techno-elitist myopia. This is the tail-wagging-the-dog part of the post.
Users don’t make spreadsheets just because they don’t know
Java. They make them because they like them, and because they
want to make them. I can think of at least two reasons why.
First, the spreadsheets often fill an empty hole. They are created, not
because the end users desperately needed them, but because one member of
the group had the ability to create them and enjoyed filling the
gap for the group. It’s one part self-expression, one part learning,
and two parts showing off.
Second, spreadsheets are inherently controllable by the end user. Sure, a
small, user-focused development shop with a simple app can turn changes
around really quickly. But, if a user wants, say, a new column added to a
report view, it takes longer to email and ask the developers to add it than
it would to just select and insert a column in Excel. I know we’re
not talking about big companies here, but something I witnessed in
Corporate America is that end users would guard their little Excel/Access
"applications" from their IT departments as if hording treasure.
As soon as they lost control, and their apps were "upgraded" to
some kind of super-scalable J2EE monstrosity (custom-developed
just for them—the long tail in action), their applications
would become (maybe) more generally useful and (definitely) less
specifically useful. Changes took a long time. They apps didn’t act
exactly as they liked. The secret spreadsheets would often see an
underground revival after the spotlight moved on.
We developers are getting excited over the opportunity to develop small
apps for small bases of users. But we might be attempting to apply a sustaining
technology solution where there is a disruptive technology waiting to
shake things up.
As developers, we see problems in terms of the potential applications we
could write. We even tend to see the spreadsheet itself as a problem. So we
naturally want to save users from themselves and give them a real
But what these "long tail" users often really want is a
spreadsheet. So why aren’t we solving the real problems with
spreadsheets instead of trying to get rid of them?
I’ve had the privilege to test and experiment with an early version
of a piece of software that is trying to solve this problem. Avi Bryant
(the brains behind the incredibly innovative Seaside web framework) and Andrew
Catton’s company, Smallthought
have created a product called Dabble. From Dabble’s web page,
Dabble combines the best of group spreadsheets, custom databases, and intranet web applications into a new way to manage and share your information online.
Or, you can just think of it as the application that solves the problem
that Nathaniel, Sam Ruby, and I are talking about in these posts. And it
does a fantastic job of it.
I built two of my own not-an-applications with it while I was testing it.
One was a fairly simple contact manager for my other nonprofit (We’ve been
using Yahoo "databases" and text files).
The other was a re-implementation of the Rails-based project management
tool, eXplain Project Management Tool
(PMT) (nice simple app, by the way—try it out). In Dabble, with
absolutely no programming, I incrementally created a project management
tool with all of the functionality of PMT in about 30 minutes. That 30
minutes included submitting bug reports and feature suggestions.
I’ve been sitting silently on Dabble for a few months now as
Smallthought has been working on it. Every time I see one of these
"Web 2.0" posts pop up in my RSS aggregator, I bite my tongue. I
don’t know what "Web 2.0" is, but I hope it’s like
this. I’m really excited about Dabble, and I can’t
wait to see what people do with it. As of today, you can sign up to be notified of Dabble’s
impending release. If you’re really lucky (unofficial word), you may
even get a beta invitation out of it.