Beyond merely functional IT

Earlier this week, GCN covered how an Alabama county's district attorney's office is using Apple hardware in the workplace. One of the factors in the hardware selection was that the sleek Macs may be spurring workers to become more creative than they would have with plain vanilla PCs, as Apple's "Think different" ad campaign suggested. Or if the computers are not spurring innovation, then at least they are not slowing down workers' creativity.

Many aspects of information technology are easy to quantify and, hence, specify on a request for proposal, such as price of the machines or how quickly the processors run. Murkier are the psychological benefits or detractions that come with IT products. Should they be considered by IT managers?

At the Embedded Systems Conference in Boston last fall, influential software developer Joel Spolsky talked about many of the intangibles that come with IT products, and how fuzzy perceptions can end up drawing sharp divisions on how IT is used.

For instance, he looked at the iPhone and the Macbook Air, both of which look totally seamless. "From an engineering perspective, you get the feeling if you accidentally swallowed [an iPhone] it'd go right down," he said. Was it an engineering necessity to remove all the protrusions that break the lines of other laptops and phones? No. But the psychological affect does translate into greater sales, and greater perceived satisfaction among users.

"Developers often think of these things as just being lipstick. They are concerned about functionality," he said. And yet it is the lipstick that can determine the success or failure of a technology—and this is as true for enterprise applications as it is for consumer gadgets.

Such subliminal influences can not only be designed into the technology itself, but even from the language that is used to describe the technology.

Spolsky spoke about something called "culture code," a term invented by a French anthropologist to describe how the perception people have about things can be influenced by the language they hear about such things. The language creates an "emotional space," that listeners can identify with.

He looked at how culture code around two different programming languages, Ruby and Python. Both languages can be used to do the same sorts of Web application development, and each had its own distinct set of users.

"It's hard to imagine that culture code applies to programming languages but it does," he said. "I thought the Ruby users were kind of Emo, while the Python users were kind of nerds, and I didn't know why this was happening because the languages were very, very similar." (Emo is a name of a youth subculture that favors dark clothing and moody, emotional music).

Part of the reason for these two different perceptions of these two similar programming languages may lie in the way each language was been introduced to the developer community. Spolsky argued.

Python was created by creator Guido van Rossum in the late 1980s as an easy-to-use language. Its popularity grew by word-of-mouth, and van Rossum was never one for hyperbole, and always stressed Python's practical nature.

Ruby, on the other hand, seemed to benefit from a fair amount of flash. Notably, one online book was critical to its success, "Why's (Poignant) Guide to Ruby" by someone writing under the non de plume Why the Lucky Stiff. The Web book includes found clip art, cartoons and fancy typography, as well as asides about family matters and other issues not pertinent to the language. Overall, it had an artsy cutting-edge feel to it, a vibe that carried over to the language itself for some of its readers.

"The fact that he had these goofy cartoon foxes helped establish the culture," Spolsky said.

Another voice that propelled Ruby was David Heinemeier Hansson, a developer who created the Ruby on Rails Web framework, while working for 37Signals, a Chicago-based Web application hosting firm. Spolsky pointed out how the language that Hansson used to describe Ruby on Rails was heavy in emotionally-positive verbiage. He quoted one statement from Hansson, about how the Ruby on Rails story is:

"one of beauty, happiness, and motivation. Taking pride and pleasure in your work and in your tools. That story simply isn’t a fad, it’s a trend. A story that allows for words like passion and enthusiasm to be part of the sanctioned vocabulary of developers without the need to make excuses for yourself. Or feel embarrassed about really liking what you do.”

In any case, Hanson's words started showing up in other people's discussions, talking points and PowerPoint presentations of Ruby, and this, in the long run, influenced how the developers thought of Ruby.

"The idea [is] that you can create a culture around a product no matter how technical it is, and get people to fall in love with it, even though it really is syntactic sugar on top," he said. "It is a way to get to be best rather than most suitable."

For IT managers considering which among a competing set of products to purchase, identifying the culture code around each technology could be a useful way to factor out all the corporate marketing that influences user perceptions. On the other hand, if positive perceptions on the part of users actually spur greater productivity, should they be dismissed outright? And that's a question you can ask the closest Mac user.