Kyle Mathews :: Dreams With In

I had a great time speaking last night at Ignite Salt Lake 2 on what we're doing down at BYU with social networking in the classroom. Thanks to all the organizers, sponsors, and other presenters!

[In preparation for my upcoming session at Drupalcon, I'll be writing a short series of articles on social networking and learning theory. First up is an article on social objects.]

“The Social Object, in a nutshell, is the reason two people are talking to each other, as opposed to talking to somebody else.” -- Hugh Macleod

As humans we like to socialize but in order to socialize, we need a reason to get together. Social objects provide that reason.

Some examples:

You and John are coworkers on a team working on the launch of a new microsite for your company. Your company, team, and project are all social objects.

You and Fred are both Information Systems majors and have become friends as you study for tests and do homework together. Your major, classes, and homework assignments are social objects.

Your wife wants to throw a big birthday party for you so she can invite all of her and your friends. The birthday party is a social object.

Sue holds a tea party every Sunday evening. She invites all her friends and they come as they can. The tea party is a social object.

Social objects bind us together. The more important a social object is to us, the stronger it'll bind us to others who also hold that social object. I love Drupal and spend a good part of my time using it to build cool websites. As I meet others who also loves Drupal, we immediately have a strong connection through that shared social object.

When you meet someone new or go on a first date, you start asking questions hoping to find “something in common” or shared social objects.

If you date someone for a few months then break up, the reason you'll often give is, “we just didn't have much in common.”

Families develop traditions. My family eats fancy sandwiches each Christmas Eve. The shared memories and rituals we've developed bind us together. Traditions are social objects.

Social objects come in all sorts of types and strength. Good social objects are complex and have lots of hooks around which to start conversations. A football game has history, statistics, personalities, rivalries, and a plot with heroes, goats, and momentum shifts. All of which provide rich meat for discussion before, during and after the game.

We change our behavior because of social objects. If your coworkers are NBA fans and there's a big game one night, you'll watch the game so you can talk about it with your coworkers the next day. You buy that silly new iPhone app so you can share it with your coworkers. You join Facebook because all your friends are there. The NBA game, your new iPhone app, and Facebook are all social objects.

But it's important to remember that it's not the social objects that matter but people. Loving and being loved is what matters. Social objects are just the tool we use to make it happen.

Next I'll write about how social object theory can help us build better social networking websites.

To read more on the topic, see my delicious bookmarks for social objects.

Presentation from one of my classes in Information Systems.

Since I read this quote by Clay Shirky, "process is an embedded reaction to prior stupidity" it's been at the top of my very long Shirky quote list. For someone like me who thrives on doing things, bureaucracy is a nightmare.

Another of my favorite authors, Paul Graham, wrote a great essay along the same vein today, talking about the gradual build-up of checks and processes and the very real cost those checks impose upon all of us.

Some of my favorite parts:

One of the differences between big companies and startups is that big companies tend to have developed procedures to protect themselves against mistakes. A startup walks like a toddler, bashing into things and falling over all the time. A big company is more deliberate.

The gradual accumulation of checks in an organization is a kind of learning, based on disasters that have happened to it or others like it. After giving a contract to a supplier who goes bankrupt and fails to deliver, for example, a company might require all suppliers to prove they're solvent before submitting bids.

As companies grow they invariably get more such checks, either in response to disasters they've suffered, or (probably more often) by hiring people from bigger companies who bring with them customs for protecting against new types of disasters.

It's natural for organizations to learn from mistakes. The problem is, people who propose new checks almost never consider that the check itself has a cost.

. . . .

Whenever someone in an organization proposes to add a new check, they should have to explain not just the benefit but the cost. No matter how bad a job they did of analyzing it, this meta-check would at least remind everyone there had to be a cost, and send them looking for it.

If companies started doing that, they'd find some surprises. Joel Spolsky recently spoke at Y Combinator about selling software to corporate customers. He said that in most companies software costing up to about $1000 could be bought by individual managers without any additional approvals. Above that threshold, software purchases generally had to be approved by a committee. But babysitting this process was so expensive for software vendors that it didn't make sense to charge less than $50,000. Which means if you're making something you might otherwise have charged $5000 for, you have to sell it for $50,000 instead.

The purpose of the committee is presumably to ensure that the company doesn't waste money. And yet the result is that the company pays 10 times as much.

. . . .

In more recent times, Sarbanes-Oxley has practically destroyed the US IPO market [Ha! My accounting teachers never mentioned this]. That wasn't the intention of the legislators who wrote it. They just wanted to add a few more checks on public companies. But they forgot to consider the cost. They forgot that companies about to go public are usually rather stretched, and that the weight of a few extra checks that might be easy for General Electric to bear are enough to prevent younger companies from being public at all.

. . . .

Programmers are unlike many types of workers in that the best ones actually prefer to work hard. This doesn't seem to be the case in most types of work. When I worked in fast food, we didn't prefer the busy times. And when I used to mow lawns, I definitely didn't prefer it when the grass was long after a week of rain.

Programmers, though, like it better when they write more code. Or more precisely, when they release more code. Programmers like to make a difference. Good ones, anyway.

Great stuff, read the whole thing.