Given that technology development involves software engineering, it shouldn’t be all that surprising that, historically, an engineering mindset shaped the development of technology. Systems were designed, tested, and then deployed. This certainly made sense when software was shipped on disks to stores to be purchased, but the same patterns applied to early web development as well. Sure, bug fixes were shipped and new versions came out more quickly online, but the terms „beta“ and „version 2.1“ actually meant something in the early days.
Friendster killed the beta. Even two years after launch, with millions of users,
Friendster still labeled itself beta. Friendster’s beta status was a source of immense laughter at geek events. By that point, Friendster had gone through so many iterations that people were speculating that Friendster would never leave beta. (Of course, most of their „developments” involved removing features instead of adding them.) Given this, frustrated onlookers questioned what beta could possibly mean.
The only answer that the snarky amongst us could come up with was that beta
meant not-yet-profitable. What is confusing about Friendster and many other projects under the social software umbrella is that the people behind these technologies are approaching design and deployment in a fundamentally different way. Rather than building locked-down versions, the designers of these systems are „shipping“ hacked up systems and constantly morphing them depending on how people used them.
Let’s return for a moment to thinking about the traditional software design process. Anyone who has ever worked in a large technology company knows the pain of this process. An idea emerges, dramatic process ensues (usually involving Powerpoint decks and monetization justification and market speculation and blah blah blah), the product people design a spec4, the engineers build it to that spec, the quality assurance team tests the system, the usability people make certain that people can use it, the legal team makes certain that it can be shipped (and adds unreadable mumbo jumbo and a button to sign away your firstborn), the marketing team builds
out a deployment plan, and on and on and on… until you die of bureaucratic
overload before the product ever ships. No wonder things take years to gestate and so many people quit burnt out from meetings!
Let’s now look at a piece of social software that bucks this traditional process in nearly every way: MySpace. The folks behind MySpace thought that Friendster was lame and making foolish decisions; they thought they could do better (just like every major corporation out there). They hacked together some code based on Cold Fusion (which, for the non-technical readers, makes most engineers shudder) and put it on the web. They invited their friends, those who didn’t want to be on a dating site, and those who were getting kicked off of Friendster to join. There was no spec, no quality assurance, no usability… (OMG there was no usability…) There was no legal, no marketing. They just deployed. From idea to deployment, it was a matter of months. No traditional company could even begin to compete in that time frame.
It’s easy to shrug our shoulders and say, well, they just got lucky… but that’s not the full story. After the system deployed, they started talking to their users. They reached out to musicians and asked how they could support them better. For example, they created the simple URL (y’know - myspace.com/tom) to help bands advertise their profiles. They watched what weird things people did and the figured out how to support that.
Compared to MySpace, Friendster is a traditional dinosaur. With MySpace, things were so rapid that you’d miss something if you didn’t log in hourly. They coded straight to live servers and when bugs brought down the system, they apologized.
When users clamored for a feature, they tried to provide for them (even if this
provisioning was held off to make them more money). When people starting
hacking the system, they allowed it and even made it easier (except for those who took this power too far). Even as they grew, rather than hiring quality assurance or usability teams, their founder preferred to hang out on the system and respond to people’s reactions. If people complained, they changed it… if people reported bugs, they fixed it. Why go through the layers of time-consuming bureaucracy to launch something when your users could tell if you it was working or not? Furthermore, why create specs when you can just launch features piecemeal and see if they take off? Of course, tell this to any traditional exec and you might be accused of involuntary manslaughter for the heart attack you spark.
Of course, MySpace is extreme in its practices, and the costs are phenomenal. You will be hard-pressed to find a time when Tom Anderson (one of the site’s founders) is not on the site unless he is sleeping. And he doesn’t really do much of that. But this ethos reflects some of the key design values of the social software movement:
1) Hack it up, get it out there.
2) Learn from your users and evolve the system with them.
3) Make your presence known to your users and invite them to provide feedback.
4) When you make mistakes, grovel for forgiveness; you’re human too!
Needless to say, there are pros and cons to each of these common practices. Let me just highlight one of each.
First, a CON. This approach produces terribly unstable code that is poorly
documented, fails any extensibility test, and is often held together by magic that not even the engineers understand. As a result, once these systems are out and rolling, plumbers are constantly needed to plug the leaks. Of course, by apologizing profusely, this can be considered a feature, not a bug.
More importantly, a PRO. Usability is based on a human interaction paradigm.
Bring a potential user into the lab, give them a set of tasks to do and see how well they understand the system. Sure, this process has allowed people to figure out how many pixels wide things have to be and how to label a button, but it’s nearly useless for social software. As any pop sociologist knows, when groups gather, the behavior of the crowd is always different than the behavior of the individuals. This is even more true online where the mischievous side of so many people’s imagination takes hold. And it is magnified by the size of the crowd. In this way, Shirky’s later definition of social software is extremely appropriate - social software is indeed stuff worth spamming because you know you’ll have an audience. No lab study can properly capture the dynamics that engender such peculiarities.
Good woman yourself danah. All that learning and experience nicely condensed in such a neat little post.
.jpeg)
