This is part one in a series about ways you can deal with the trials and tribulations of a growing user community. Part two will be posted in the next few days and will deal with iterating on your site’s features and usability in order to accomodate the needs of your user base. Interested? Subscribe to my feed to keep informed of new additions to the series.

As many of you are aware, the reason I’ve been quiet over here of late is because I’ve been busy maintaining Protagonize and blogging regularly (in video and otherwise) on the official Protagonize blog.

What you may not be aware of is that the site is growing quite steadily, and with little fanfare, is starting to run in to the inevitable growing pains that social networks and communities tend to experience in their formative months (and years.)

I thought it would be useful to explore and discuss some of these issues, without getting into serious technical detail. If you can manage to avoid these problems, you’re well ahead of the pack.

Ouch, that hurts

These days, you can’t toss a brick without hitting another blog post or microblog entry about Twitter’s downtime issues and inferior system architecture. While I don’t disagree that they’re not scaling very well to meet demand, I will state that I doubt the system was originally designed to handle the kind of exponential growth and volume they’re seeing right now. With over a million registered users, and some incredibly vocal and/or popular members — such as Robert Scoble (who appears to have toned down his Twitter usage in recent days), Jason Calacanis, or Leo Laporte — Twitter is experiencing inevitable growing pains. All three of these social media heavyweights have upwards of 25,000 followers and “tweet” on a regular basis. Apparently, this causes Twitter to have fits. While many have tried to blame their technology platform, Ruby on Rails, for the scalability issues, Twitter has gone so far as to shift the blame to these highly-followed users for some of the architectural issues they’re currently suffering from.

While some sporadic downtime would be understandable for most organizations in Twitter’s situation — where they’ve generated massive amounts of traffic in a relatively short span of time — much of Twitter’s user base consists of edge cases: hardcore early-adopters and tech-savvy users familiar with social media, neither of which is coping with the frequent downtime well (though one might assume those more in the know would be more forgiving.) Every big event, with Apple keynote speeches and conferences like SXSW leading the charge, seems to cause them more and more grief. This leads to hordes of disillusioned users complaining about their application, ON their application. You know what they say about all press being good press? It’s not so great if the bulk that bad press is being dispersed using your software.

Early adopters are notoriously fickle creatures, generally willing to jump ship to the “next big thing”, be it a similar service (remember Pownce? I’m still not using it), or a shiny new toy with a little overlap (Friendfeed, Pluck, or Brightkite.) Amusingly enough, Plurk and Brightkite are starting to run into similar issues of scale, with significant downtime since the media blitz they suffered about a week ago. Twitter, on the other hand, is a veteran in the lifestreaming world and is slowly starting to break into the mainstream, but if they don’t get their architectural issues dealt with quickly, they’re going to miss the boat. Is Twitter the next Friendster, unable to capitalize on a rabid, exponentially expanding user base and great press coverage? I sure hope not, because as a community developer, I’m completely able to understand their situation.

The pitfalls of rapid development

Most of the largest and most popular applications developed during the unfortunately named Web 2.0 era have been built by small development teams with limited (or non-existent) budgets. Very few were backed by large organizations with deep pockets before launching and reaching a tipping point of some kind. This approach makes getting a new site off the ground cheap and simple, requiring only time and elbow grease, but little in terms of funds or manpower.

The converse dilemma created by this approach is that lack of sufficient time, funding, or staff creates a vaccuum effect. Regular best practices of software design and maintenance — which would normally be standard fare for any large-scale application with a proper release cycle in place — start to fall by the wayside to accomodate new, off-the-cuff features, designed to meet the ever-expanding user base’s demands. Why is this? Because you’ll hear from your power users — your community evangelists, if you treat them right — on a regular basis. They’ll message you, they’ll complain, they’ll tell you when something’s wrong, and eventually, they’ll give you suggestions. All of this, be it negative or positive, is good feedback to aggregate and parse. If you’re not hearing anything at all from your users, you’re probably in a pretty deep hole and should start making attempts to communicate with your community on a regular basis.

Maintaining the uneasy balance

The issue at hand is keeping system architecture and maintenance in a balance with new features. For instance, your users won’t likely be aware of the fact that your application server’s single CPU is running at 100% with only a handful of simultaneous users. They’ll just see that a page is taking an inordinate amount of time to load, or a server error due to a timeout, and they’ll bail out on you. They’ll vent at you, telling you that one feature or another needs to be added, or fixed, or tweaked to their specifications. Take this with a grain of salt, but don’t forget it altogether.

With Protagonize, I try and maintain a balance, alternating site optimization and performance or usability enhancements with new feature development. It’s obviously a gargantuan task, with a staff of one (part-time, to boot!), but if you parcel out your tasks accordingly, it can definitely be accomplished.

Formulate a Roadmap

I have a to-do list (that I maintain on on Basecamp) that’s a good 300+ items long. It’s basically a rough product roadmap for Protagonize, that I’ll build on as the site grows and as I have more time to develop it. I chip away at these tasks one by one, organizing them by priority and by type of task. Outstanding bug fixes, while there aren’t many, rank high on the list, as do serious performance deficiencies that need to be addressed immediately. At the same time, major new features are ranked by necessity and spread out evenly amongst maintenance-related tasks.

Try and break your task list down so that you can get a few small changes in before taking on something big — this makes you feel like you’re actually accomplishing something, and surprisingly, the smallest of changes on your site can make your users supremely happy. A tiny change like extending the story editing window to 24 hours (from one hour) on Protagonize generated all sorts of thanks from my members. Little things add up, so try and squeeze a few in before you take on a major feature.

Communicate with your users

Everyone is familiar with the “Digg effect”, “getting Slashdotted”, “being Techcrunched”, or any number of other variants on the theme of getting hit with (and succumbing to) a huge influx of users in a very short span of time. Most people are understanding of this kind of downtime, as it’s a one-off, unpredictable occurrence and is generally due to a major spike in traffic for a short span of time, measured in hours (or worse yet, days.) What people aren’t willing to put up with is extended downtime or system sluggishness with no obvious cause. If something is causing your site to run slowly, or requires a server maintenance window longer than a few minutes, communicate this with your users. The importance of a good back-and-forth discussion with your community cannot be understated. They’ll be much more willing to suffer through the tough times if they’re not in the dark.

Joshua Porter’s newly published book, Designing for the Social Web (affiliate link), has some excellent examples of how to communicate change with users in chapter 3, “Authentic Conversations”. I recommend this book to anyone building or managing a community — the advice Porter offers is invaluable, especially customer-relations case studies such as Dreamhost’s billing nightmare earlier this year, or the “Dell Hell” episode. His blog, Bokardo, is also definitely worth subscribing to, as he writes articles about community building on a regular basis (much of which provided fodder for his book.)

Sympathy for the Goliath

While I don’t (quite) have the audacity to compare Protagonize to a site that has over 500 times the number of registered users, I’ve discovered that nothing really compares to speaking from experience. I can definitely feel some sympathy for Twitter’s precarious position. As Protagonize’s user base has ramped up from a couple of hundred users to several thousand, I’m noticing issues with the site where none were obvious before. Most of this is because I just didn’t have the time or resources to properly load test the site when I developed it (and still don’t, to some extent.) Some of it is due to poor architectural decisions that I’ve since overhauled, and some of it is simply due to a lack of development time. Either way, your users won’t quickly forgive you unless you communicate with them, and make serious attempts to resolve the situation at hand in a timely fashion.

Features you may add as an afterthought can and will work against you if you let them. A rushed change can wreak all sorts of havoc if you let it, but it may not become obvious until much later. Basic additions, such as the addition of images to user profiles, something I added a few weeks after launching Protagonize, have a way of coming back to bite you in the ass if you don’t plan for them properly. Worse yet, they can become obfuscated by other issues or complexity that you’ve introduced since that point.

Small changes can spell big trouble

The problem in my case, without boring you too much with technical jargon, was that all database queries that pulled back user data were suddenly pulling back image information as well. While I store all of the user images on the filesystem for faster access, Protagonize has an original source copy of each image in the user records stored in the database as well. I added profile images well after the original site was built, and I was hurried while doing it. The result was that with a large influx of users, pages making user requests (especially aggregator pages like our central Authors page) were suffering from longer and longer load times. More comical still was the fact that we had dealt with a similar issue last year when I worked on ThoughtFarmer and it had totally slipped my mind.

Of course, as a developer, I immediately thought it was one of the more complex queries strewn around the page that was slowing things down. I proceeded to make little optimizations here and there to try and make things faster. Only after two days of tweaking did the thought occur to me that it might be the images on user records that were causing the excessive slowness. A half-hour later, I had the problem solved, and any page loading author information was suddenly loading a good five times faster. I have no idea how many potential new users I may have lost due to the sluggishness of various pages around the site, and I don’t really want to think about it, to be honest. :)

This all comes back to the fact that while the smallest of changes can please your audience to no end, it can also break stuff rather badly as well. I learned my lesson the hard way. While I don’t plan on repeating the experience, I’ll concede that it’s entirely possible it can happen again due to the way I work and iterate on the site rapidly. I can, however, take precautions against this kind of thing happening again. Now that I’m aware of the impact of a larger user base, I’ll be more careful with seemingly insignificant additions in the future. I can’t imagine the impact it would have had if my site’s membership was anywhere near the size of Twitter’s. My understanding for their troubles in recent weeks grows as I start to feel similar issues, even on a smaller scale.

In part two, I’ll discuss how to approach developing your site’s features incrementally and responding to user feedback, positive or negative.

Photo credit: yoannlb on Flickr.

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Posted in Collaboration, Community Building, General, Social Media |