Infovark

I couldn’t resist checking out the Nerd Handbook on Rands in Repose this morning. If you’re a nerd, or have a nerd in your life, it’s a funny article. If you don’t have a nerd in your life, you can just imagine me instead. (Case in point: I began reading Rands’ blog after reading his essay in Joel on Software’s Best Software Writing I. That’s nerdy.)

Rands asserts that nerds have an efficient relevancy engine inside their heads. This relevancy engine can be extremely annoying, since every item of information given to a nerd has to pass an “Is it interesting?” test before it is remembered or acted upon. And as we all know, a nerd’s definition of interesting can be quite different than the rest of humanity.

While many nerds suffer from having an extreme form of this relevancy filter, I think all of us have one. Human brains are wired to be pattern-matching machines. It’s what lets us recognize faces from a block away, a song from a handful of notes, or the darn alarm clock by fumbling in the dark. We can even see patterns where none exist, which can cause us to believe in things like the abominable snowman or Nessie. We’re naturally good at separating the signal from the noise.

Unfortunately for anyone that works with computers, this is precisely not the way that computers think. When people first built computers, they built them to compute. Performing complex calculations is a tedious and error-prone task, so we created a tool that was very good at it. This allowed scientists, engineers and mathematicians to get on with the more interesting parts of their work while letting the computer crunch the numbers.

Despite all the fancy bells and whistles that have been added over the years, the heart of a computer is still its central processing unit (CPU). The CPU is really nothing more than a souped-up pocket calculator. It expects detailed instructions about what to do, and given the right instructions and accurate data will produce a correct result.

(For some reason, I have this Kraftwerk song playing in my head right now….)

As I mentioned in a previous post about emergence, one of the main problems with enterprise software today is that it is built for the way computers think, not for the way that people think. Most enterprise tools assume that the user can articulate a detailed series of steps to follow and provide good data. But today’s knowledge worker is not merely crunching numbers or following standard operating procedures. In fact, we’ve engineered most of the raw data processing out of people’s jobs, shifting it to the computers that do it so well.

So knowledge workers need tools that help them do the kinds of work that they do today: research, analysis, synthesis, and composition. These tasks are all relational in nature. They require us to do things we’re naturally good at: find patterns, weigh evidence, determine relevance and execute judgment. And that’s where the problem lies when it comes to enterprise software. Computers just weren’t designed to help with these sorts of tasks.

One example: Recent research has shown that bees are good at facial recognition, even when the face is partially obscured. Computers struggle with this problem; it takes powerful, modern computing hardware and advanced software to approximate the accuracy of a tiny insect. In fact, it’s enough of a struggle that it made the list of Grand Challenges. The reason? Pattern matching and number crunching are fundamentally different tasks. Just as it’s hard for humans to repeatedly execute a complex series of calculations, it’s difficult for computers to draw inferences and determine relevance.

This situation leads to a Catch-22 in enterprise software. Since knowledge workers intuitively grasp patterns and relations, they often have trouble articulating their thought process or decision model. But since computers are best at executing instructions, knowledge workers are forced to lay everything out in meticulous detail. The end result is that both the software and the employee wind up doing tasks that they aren’t very good at. Is it any wonder people find working with enterprise software frustrating?

To fix the problem, we have to make software that either thinks the way we do or that can leverage the power of our power of our wetware — our relational, pattern-matching brains. Would your computer associate enterprise software with experimental ’70s synth-rock? No, but I’d bet I’m not the first person to do so.

(Yeah, the other one was probably also a nerd. )

If you’re following the world of Enterprise 2.0 closely, you might want to take a close look at the results of this new study on office productivity

“According to a groundbreaking new study by the Department of Labor, working—the physical act of engaging in a productive job-related activity—may greatly increase the amount of work accomplished during the workday, especially when compared with the more common practices of wasting time and not working.”

I think there’s something in that for all of us…

A friend of mine was lamenting the corporate blog phenomenon the other day:

“It’s the ‘I would like to have a lovely conversation with you. About snake oil.’ tenor which so many of them seem to have. It’s so… demeaning. “

Hmmm. Consider:

• Steve Rubel suggests that the tech blogosphere is drunk on its own Web 2.0 Kool-Aid.
• Chris Anderson gives up and publishes the email addresses of the PR hacks who pester him with spam press.
• Whole Foods prohibits its executives from any kind of blogging or online forum participation
• Even Robert Scoble seems to have lost a bit of his enthusiasm.

Corporate blogging is a weird subset of the blogosphere, and maybe its bubble is about to burst. It does seem to have come to some kind of introspective adolescent crossroads.

(Mind you, corporate blogging is what I’m doing now. It’s alive and well here at infovark.)

Corporate Gord says: “Buy This!”

(Cartoon via Hugh Mcleod)

Personally, I still see plenty of value in corporate blogs. I don’t have a problem with crummy “Your Call Is Important To Us” press-release-style astroturf content. It tells me that their organization doesn’t understand permission marketing. It tells me that they follow internet trends without truly understanding them. Companies like that aren’t the kinds of companies I want to buy things from.

But I’m glad that I can see this on their corporate blogs. It makes my purchasing decisions a lot easier. As an example, the OpenText Blog tells me nothing personal or insightful — it just presents lots of case studies and PR stuff about how clever OpenText are. Similarly, the Microsoft Enterprise Content Management Blog contains nothing but detailed technical information about SharePoint.

On the positive side, lots of companies are better because of blogging. As an example, I’d always felt that Oracle were a bunch of cold, mean, database robots who delighted in making software so complicated it made me cry. But after reading the blogs of people like Billy Cripe, Bex Huff. and the Oracle Apps Lab team, I’ve come to view them in a different light. (Now I realize the robots actually have feelings!)

I predict the more boring, hype-laden, PR-driven blogs will disappear as old-school companies gradually realize they are doing themselves more harm than good. They’ll go back to older, safer ways of pushing as little content as possible while hoping that their customers will still turn up to buy stuff.

Best of luck with that.

In a recent post, Gordon talked about deploying Enterprise 2.0 tools in an emergent way. But what about the software itself? What characteristics make software emergent?

Emergence can mean several different things. The classic definition is that something has emergent properties when simple interactions lead to complex results. It usually carries with it the notion of repeated interactions. While you generally hear it used in a positive sense, as in “the sum is greater than the parts”, in can also lead to negative effects, as the designers of the Tacoma Narrows bridge discovered. Emergent doesn’t necessarily mean unpredictable, however. Many fractals have emergent repeating patterns but can be fully described by simple mathematical or geometric operations.

As a buzzword, emergence is often paired with social media. (Probably because geeks have a hard time with the idea of limited social interactions leading to complex group behavior.) But it’s true that sometimes a team can accomplish more than individuals acting alone. And it’s also true that rational individuals can get swept up in a mob, or fall for an investment bubble. Or that a short document listing founding principles can lead to a complex, multi-layered government system.

Writing software that exhibits emergent qualities is both very easy and very hard. It’s easy because there’s not much to program: Put your handful of rules in place and ship the product. But it’s also very hard, because once your audience starts working with the software, they may discover things you never intended.

Companies making computer games often release patches to tweak game mechanics, balancing the game so that no opponent has a greater advantage. Supporting a massively multiplayer online game requires constant monitoring to keep the experience just right. I think those of us writing emergent software for the enterprise could learn a thing or two from these games. If you’re interested in being an emergent software vendor, you can’t think like a manufacturer of shrink-wrapped boxes. The old programming joke becomes reality: The software isn’t done until the last user dies. You are an important part of your user community.

It also provides added incentive to avoid feature creep or featuritis. After all, if simple interactions can lead to complex behavior, where will complex interactions take us? Adding unnecessary features can add clutter to the interface, confuse users, introduce bugs, and ultimately cause unintended errors. All of which will drive your customers to adopt a smaller, cleaner product that does just what they need.

Most of all, writing emergent software requires a new attitude. The traditional way of thinking about software programs is that they are the means by which a user instructs a computer what to do. It’s a common trap that software companies fall into because that’s the way their programmers interact with computers. But the goal of your customers is not to tell the computer how to do things, but simply to get things done. The fewer instructions a user has to give the computer to get the job done, the more responsive and intuitive the program will feel.

To write emergent software, you have to shift your focus from the user interacting with the machine to people interacting with other people.