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 spreadsheet stuff.
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 application.
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.