Just freewheeling on social software and communities

Kyle Mathews, while commenting on a recent post of mine, reminded me of an old Joel Spolsky post on building communities with software.  I remember being very taken with the post when it came out all those years ago, particularly what Joel called “the primary axiom of online communities”:

Small software implementation details result in big differences in the way the community develops, behaves, and feels.

I think that there’s one huge difference between the context in which Joel wrote this and the context in which we live today, a difference that is material to many of the discussions we have.

As a result of the ways we can build software now, we can lower the barriers to entry; at the same time, it is possible for us to keep the cost of change low as well.

Where Web 2.0 meets social software, we’re still at a relatively early stage. A stage where we’re still experimenting. One where we have ardent admirers and passionate critics of everything that’s going on. And it’s too easy to make the mistake of thinking that the message we hear in the media reflects what’s really going on. Because it doesn’t.

There are a lot of people playing in earnest with the software available, be it Facebook or Netvibes or Plaxo or Myspace or Twitter or whatever. And while they play, they learn. What works. What doesn’t work. These people have an answer to the Ugly Question, their observations and criticisms are based on real use. And they provide real feedback.

What occurs to me is that in the past, Joel’s “primary axiom” had some very painful consequences. When people got the “small software implementation details” wrong, the cost of change was immense, and the community suffered as a result. Sometimes the suffering was terminal.

Today things are different. Competitors can enter more quickly and more easily. There is an adaptive feel to what’s going on, and much of that feel is driven by conscious and demonstrable reduction in the cost of change.

More on this later, I suggest you read the Spolsky post for yourself, I’ve provided you with the links above. Also, it looks as if it may well be worth following what Kyle is planning to write about, so do bear that in mind. Kyle also refers to a Clay Shirky post (on communities, audiences and scale) that’s well worth reading again. I particularly like the way Clay distinguishes between audiences and communities. Incidentally, Kyle’s post gives me a new perspective about why I dislike the word “content”; something went a-ha in my head when I saw this:

what is the difference between audiences and communities? Audiences primarily consume content, communities primarily communicate with one another.

Also incidentally, you may have noticed Stephen Smoliar make one of his rare comments yesterday, one that I am still thinking through. I had been revisiting the concept of wasted time, and Stephen reminded me of the prior threads related to this subject, where his noun-verb arguments and some of the product-service arguments had been continuing. This time around, he went on to say:

Thus, there is a deeper problem that arises from this whole shift from a production economy to a service economy. It is not so much a question of wasting time. It may not even be a question of “productivity,” if “production” is not the primary goal of the work. Rather, it is the need for a new model of compensation that is commensurate with both how services are rendered and with what service providers do during their “down time” in order to be better at rendering those services. Are the corporate bean-counters ready to get their heads around that question? :-)

Absolutely.

Lots of stuff to mull over. Which I shall be doing over the next few weeks. With your comments and your help.

5 thoughts on “Just freewheeling on social software and communities”

  1. I find it kind of ironic, however, that Joel doesn’t really get behind Agile development. Most of his recent articles around it really feel anti-Agile. So, just how much can he lower the cost of change?

  2. JP, when you say “Absolutely,” are you speaking as one of the bean-counters; or are you just confirming the validity of the question? I do not know what things are like in YOUR enterprise; but, on this side of the pond, I have yet to find a bean-counter who can think beyond the data for the next quarterly report! Indeed, one of the scariest things about the IBM “rush” into “services science” is how little thought is being given to compensation models, “scientific” or otherwise.

    http://blog.360.yahoo.com/blog-Mff23hgidqmHGqbcv.lfskakEtS6qLVHUEMFUG4-?cq=1&p=82

  3. Andy, I’m intrigued by what you say. I read Joel regularly, and he hasn’t come across that way to me. If anything, my take was that he supports Agile quite openly, but has major reservations about the extent to which Agile has been systematised in certain quarters. Do you have references to posts or articles where he slams Agile? I have seen some that slam some forms of XP, and some that suggest that people are fossilising what is meant to be an adaptive process.

    And I don’t understand your other point about how he lowers the cost of change. It’s not about him or you or me. It’s about the way we develop software nowadays.

  4. To be fair, I’m searching for a few and coming up a bit short. Definitely agree that he’s against some practices of XP (pair programming) but he’s not the first or last. He insists that developers get their own offices w/ doors that shut (http://www.joelonsoftware.com/items/2006/07/30.html), which, to me, doesn’t feel like any agile team I’ve been on. Being able to sit together and feel like you’re a part of the whole team is very important to me. But, to your point, I can’t find anything where he’s against Agile. Just a bit less of the practices I prefer, and a bit more of some that I don’t (a bit more Design Up Front than I like, but not Big Design Up Front). He prefers to work from a spec, which isn’t a bad thing but can go wrong fast. (http://www.joelonsoftware.com/articles/fog0000000036.html). A good spec is valuable, but sometimes challenging. And spending a lot of time on the spec rather than the software is detrimental. I haven’t seen him make any mention of TDD, rather you should make time for Debugging sessions (something that I hardly ever do when I have a good suite of tests) (http://www.joelonsoftware.com/articles/fog0000000245.html).

    Looking at the Joel Tests (http://www.joelonsoftware.com/articles/fog0000000043.html) I can see Agility in there. It’s just not the Agile I know, and I’m fully aware he’s adapted his processes to work for him which is good.

    As for lowering the cost of change, I believe you must use Agile principles when we develop software in order to lower the cost of change. If you don’t use Agile principles, then you don’t adapt to change fast enough (or at all). That was my only point. If you aren’t using Agile, you likely aren’t lowering the cost of change as you develop software.

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.