Karlin Fox had a great talk at RubyConf about the work he’s been doing on Systir, a framework that aims to allow customers to write their own system tests (also known in some circles as acceptance tests). This is something that I’ve done in the past, and which I talked a bit about at RubyConf 2002 in my talk entitled, Are We There Yet? Thoughts on Acceptance Testing.

One of the things I discovered when working on customer-facing tests in mid- to large-size companies was that it’s hard to get customers to write tests themselves. There’s actually a decent chance on any given project that the customer will refuse to write tests. Not refuse in a mean, “No mother I won’t eat my BROCCOLI!” kind of way, but refuse in a, “I’ve got a million things to do and could you please take care of all that software stuff?” kind of way.

So what ends up happening? Well, the developers (and testers, if there are any) write the tests, and life goes on. Actually, it turns out that there’s still a lot of value in writing the tests in language that the customer can understand, because then they can read the tests that are being produced and provide direct feedback on them, and they might at some point write some themselves. It also forces the developers to think in the domain, which helps them to understand the requirements more deeply and see more clearly what needs to be done.

Interesting and all, but what’s this got to do with the long tail of software? Well, Sam Ruby wrote a very interesting post over at intertwingly that said (among other things – you should read the whole thing):

Nathaniel told an anecdote about an organization that his wife belonged to which had developed a financial application. In Excel of all things. As if there was something wrong with that. You could almost see Nathaniel roll his eyes.

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 won’t 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.

I agree that we’re going to see more applications written in Excel. And I think most of them are going to be as awfully un-useful as the spreadsheet that my wife’s co-op is limping along with. You see, the issue I have with Excel “applications” is not that they’re written in Excel – one should use the best tool for the job, and for some things I’m sure Excel is the right tool. The problem I have is that the majority of apps that are being shoe-horned in to Excel don’t fit there. I really believe the co-op would be better served by a few printed templates filled out by hand than they are by their current spreadsheet – it handles none of the hard problems for them and creates problems of its own. They’d be served even better by a customized application targeted right at their domain by a skilled craftsman.

This is the promise I see in the long tail – that users will be able to get small, customized applications that are really good at doing exactly what they need done, instead of having to cobble together their own software that, frankly, doesn’t work very well. The economics are just getting to this point – actually, I’m not sure they’re quite there yet, but I do think they’re close.

Do you think painters like making frames? I’m sure a few do, but generally they’d much rather go down to a frame shop and get someone who’s good at frame-making to custom build a frame just for their painting. If it was too expensive to get custom frames, then they might very well make their own, but better to leave the frame-making to the frame-makers.

Why do users build their own software today? Is it because they like doing it? I’d say that’s a minority of cases. Just like most customers don’t want to write tests, most users don’t really want to write software – they just want the end result that lets them do the things they’re really after, and attempting to create it themselves is the only path they’ve had to get there. I bet they’d generally rather go to the corner software shop and get a custom piece of software just for them.

Now the interesting thing is, making systems that allow cheaper, more user-centric programming will help developers even if users aren’t generally interested in developing. If we’re building lots of little software projects that are used by lots of little niche groups, it would be nice if those users could tweak the software themselves. Just like writing tests in language that the customer understands allows them to be more involved and try their hand at test-writing now and then, users who don’t necessarily want to build the whole enchilada might like adding condiments themselves.

So what am I saying? Well, there’s no doubt that as development gets easier and more intuitive, it will allow more people to create software, which is a good thing. But, I truly believe that the average person who would like to use software doesn’t want to write software. Developers are not only good at writing software, they like doing it. Sounds like a match made in heaven, if users of software can afford to directly support developers of software. I truly believe Ruby (and particularly the Rails framework) are going to be enablers for just such an economic model, and I’m excited to see if I’m right.