Don Marti

Wed 05 Jul 2006 06:00:31 PM PDT

Code monkey like relevance

JP lists some reasons why enterprise immune systems tend to try and reject the implementation of social software".

Here's a missing one: "Not My Department. Social software is nifty, but it's for the Technical Side of the company. We're on the Business Side, so we're going to use anti-social software. So just give me the bullet points."

Why does the half-networked company happen? The blame lies half with the software, half with the company. First, social software for companies has two problems. Problem number 1: Offline. The big cheese is on some conveyance that either doesn't have a net connection, or makes it impracticably slow to use social software on the laptop. Better to work locally and queue up the results as outgoing email.

Problem number 2: interface complexity. The biggest thing that social software can give you is a common repository for the status and owner of tasks that the company is doing. RT is a nice system, but much of the other social software that gets thrown at companies is too complicated to be productive for non-programmers.

Companies trying social software also have two problems. Problem number 1: Setting an example. If you're the big cheese and you want your organization to use social software, you have to use the social software. Mark Shuttleworth, for example, kicked off the Launchpad BTS with Bug 1, assigned to himself. If you answer some other form of communication before you check the social software, people in your organization who want to reach you will start using that instead. And then people who want to reach them will use it, and the social software system breaks down, sometimes within days.

Problem number 2: Ignoring workarounds. Most office workers won't complain about social software, especially if the Official Way to Complain is through clunky social software. They'll try it, and if it doesn't work, they'll just do what they set out to do using anti-social software. Actions speak louder than trouble tickets. If someone is sending out a company phone list as a spreadsheet instead of updating the directory, or big email attachments with 20 recipients start to circulate, think of it as a bug report, only done as a performance piece. What's wrong with the social software? Orkut and LinkedIn show us that social software can be easier to use than anti-social software, so it's not just a question of "people are used to office suites." Business and social software both have some hard problems to solve in order to connect with each other. JP seems to think it's worth it, and I agree.

Meanwhile, Sacha writes, "I don't want to deal with market studies and hypothetical users. I want names and faces and stories. I guess that's why software development or system administration don't really appeal to me as careers."

Sacha, saying that you don't want to be a programmer in the 21st century because you don't want Marketing between you and the user is like saying you didn't want to be a programmer in the 20th century because you didn't like waiting for the operator who carries your stack of punch cards to the computer. The way software development gets organized is always changing. It's getting lighter weight all the time.

The process of making software got three steps more productive, Fred Brooks writes, when programmers went from assembler to higher-level languages, when they went from punch cards to terminals on time-sharing systems, and when they first got pluggable pipes and filters in the Unix and Interlisp environments. After that, programming doesn't get a "silver bullet" of productivity. The underlying problems are truly complex.

But there's a good chance that we're in the middle of getting a whole speedloader-full of silver bullets if we consider the company as a whole, not just the development team. Companies are figuring out ways to use social software to break down the organizational equivalent of the Bicameral Mind. Instead of paying for Marketing to shuttle between developers and users, let the information move through peer production, connection on a basis of shared code and norms, and customer-developer turnover. Good example: Mike Olson gets the most value from open source in the form of direct user "validation of the product's value," Brian Aker reports. Wait a minute—a hacker doing journalism about business in his spare time? Exactly. And all of that is powered by social software.

Want to subscribe to the future? Read Christopher Blizzard, Brian Aker, Greg K-H, Matt Cutts and others. At the best companies, real developers don't have time for "hypothetical users" because they're already getting information directly from real ones. (I'm always looking for more examples of this phenomenon, so hit me with the RSS links, people.) Throwing Marketing in between modern developers and the users would be like starting a restaurant and hiring deep-sea Vestimentiferan worms, which live, isolated from the rest of the biosphere and never eating but deriving their energy from symbiotic sulfide-metabolizing bacteria, to write the menu. By all means avoid companies that isolate you from real users and bury you in Big Dumb Word Processor Documents, but recognize that they're going to get rarer and rarer. The software profitability crunch and the turn towards social software mean that wasteful marketing/code monkey divisions are getting squeezed out.