During a recent visit to Mumbai, I had an opportunity to shoot some video with India's CNBC-TV18. I really like the way they packaged the results: a caption that asks a question, then the fragment of our conversation with my answer.  The result is a sort of "video FAQ" about key issues of cloud computing adoption, with special emphasis on the India marketplace but also with relevance to many other markets.

You can see this material in two separate video clips at

http://tech2.in.com/biz/tv/sectionvideo.php?id=49912&secid=121&arrid=0

and

http://tech2.in.com/biz/tv/sectionvideo.php?id=49922&secid=121&arrid=0

Enjoy.

It's one of the great mysteries of our time. How can products dominate their category when people widely despise them? Why is it not enough for a developer of software, or a provider of a service, to say "It works better!" -- and get people's business with that simple statement?

A few years ago, I ran across an observation by Thomas Landauer in a book entitled "The Trouble with Computers." Don't be offended, fellow users of software, but he compares us to pigeons in a behaviorist experiment. As I summarized in a March 27, 1995 column in PC Week,

"Computers are addictive," according to Thomas Landauer, formerly a director of research at Bellcore and now a professor of psychology at the University of Colorado.

Landauer compares the frustrated end user to a pigeon pecking at a lighted key to get a pellet of food. In a famous experiment by behavioral scientist B.F. Skinner, pellets were originally given for every correct peck, then gradually reduced to random rewards, averaging one per 100 pecks. When Skinner stopped giving food entirely, Landauer reports, "the bird pecked the key 10,000 times before Skinner gave up."

In his forthcoming book, The Trouble With Computers: Usefulness, Usability, and Productivity, Landauer attributes users' tolerance for badly designed software to a similar addictive behavior. "Sometimes a very simple error defeats you. You try again. Nope. You think you see why. You try again. Nope. You think of another thing to try. You try something you've tried before, just in case the computer wasn't paying attention. Far into the night, you finally succeed. What a wonderful feeling. Thus is a psychological addiction born."

Now I find new evidence that people don't automatically seek out what works best. Writing this week in the journal Science, researchers report that

Near misses activate the same reward signals in the brain as a win. Slot machine makers capitalize on the near-miss effect. Researchers have found that they program their games to tease players with near misses about 30% of the time--a number previous studies have found optimal for getting gamblers to keep coming back...

A team led by Luke Clark of the University of Cambridge in the United Kingdom developed a simplified slot machine game on a computer...In a gambler's brain, a near miss triggered a similar pattern of brain activity as a win...

Clark says that the rewards of a near miss may have ancient origins. In skill-dependent tasks, such as hunting, people do have some control over the outcome, and trying again after a near miss could bring home the bison, he explains. "The healthy brain is looking for ways in which it can control the environment, and gambling games harness that natural system."

It's like something out of Evil Geniuses in a Nutshell: our DNA wires us to believe that if we're getting close, another try will bring us still closer. This may work for throwing spears, but it rarely works when software just isn't written very well.

What's the impact on developers? It's not enough to eliminate the pain: you also have to compete by offering superior delight plus a genuine opportunity (not just an illusion) for mastery and control.

You have to provide features that are just really cool, as well as everything that users might reasonably want -- and you have to give the users extensive options that let them tailor the user experience to personal taste, and give them a strong sense of being invested in your application.

I see that John Dvorak is blaming Intel's Itanium for having "Killed the Computer Industry". That seems like a premature obituary: overall PC unit sales in 2008 were up more than 10% versus 2007, with Gartner and iSuppli both projecting further growth (albeit only around 4%) in 2009.

I can think of plenty of people who'd be thrilled to be having that kind of "collapse" (another of JCD's hyperboles).

More interesting, to me, is the question of cause and effect -- and which is which. Dvorak asserts that the Itanium's advance hype killed off all the other promising directions in processor innovation, and that programmers are still stuck with the ancient x86 instruction set as a result.

We can't very well go back and run the experiment again, but it seems more likely to me that hardware people thought that they were still in charge of defining the industry's future -- at a time when the inertia of the worldwide base of programming skills was actually the overwhelming factor. If programmers don't know how to write correctly sweetened code, a processor's theoretical strengths are irrelevant.

Learning how to craft outstanding code for a new machine, with or without the help of a high-level language, is a skill that costs real money -- time spent, tools bought, training endured, opportunity costs incurred -- and developers need a compelling reason to make that expenditure. A mere factor of two, say, in performance is barely enough: by the time the code quality is what it needs to be, hardware price/performance improvement would likely have gotten you to the same place.

At least, that's the way it used to be -- but there's a real question of whether hardware improvement is still enough, unless programmers also embrace the techonomics of the cloud.

Managed code on managed platforms represents another big opportunity/challenge for developers, but I believe that this time -- unlike the sinking of the Itanic -- the developers will be willing to dive in and learn to swim. The cloud is where it's faster to go to market with a better product that more customers can discover, evaluate and use in less time at less cost.

Multiply all those factors of 2 (time to market), 1.5 (product usability), 1.8 (adoption) and 1.33 (favorable cost ratio) and you get something close to an overall factor of 7. Pick any reasonable values you like, you'll still come up with two or three Binary Orders of Magnitude (factors of 2, to those outside our little world). That's a 3- to 5-year jump ahead of any competition that's still writing code for single-user chunks of bare silicon.

That's a competitive edge that's finally worth what it costs to achieve it.

If you thought the infamous six blind men found too many ways to misunderstand an elephant, you don't want to face the chaos that's surrounding a current Slashdot discussion of Moore's Law. "It says things get faster!" "No. it says things get cheaper!" "No, it says you'll only actually do things if they take less than a certain threshold time to get them done!"

Wrong, wrong, wrong, and in a way that actually matters.

Moore's Law is a statement about the economics of building chips: a prediction, which has proved remarkably accurate, that optimal per-transistor cost will be found -- as time goes by -- in chip designs of ever-rising device count.

That leaves it up to chip designers to find something actually useful to do with all those devices (e.g., transistors and gates) -- and of late, the best thing they've been able to do is to build chips with ever larger numbers of processing cores. It's proven to be no small task to reoptimize software for best use of that new hardware environment.

What that means is that the future jurisdiction of Moore's Law is in realms where concurrency is easy to achieve: in places like the multi-tenant facilities of the true cloud computing service provider. The economics of the cloud are already attractive, and within the next three years (two Moore cycles) they'll be utterly compelling.

I had an adrenaline-rich opportunity to make my pitch for cloud computing, with a strict time limit of eight minutes, before a sizable audience and with subsequent (live and unrehearsed) interrogation from a panel of CIOs at this week's Cloud Connect event in Mountain View.

I freely admit that any of my usual forty-minute talks conceals a half-day seminar screaming to break free: I had to wonder if I'd have to do a FedEx commercial to avoid getting gonged after less than five hundred seconds. (A six-minute dry run gave me hope, but it's hard to resist telling a good story.)

Well, it can be done. Feel free to download the charts and let me know if you'd like any additional details.

When InformationWeek identified "Top 10 CIO Issues for 2009," I was more than happy to see "Customer-Facing Innovation" as #1.  Increasingly, that's what we do here, with capabilities like Force.com Sites complementing applications like Ideas.

Then I saw #2 on the list: "Attacking the 80/20 Ratio," shifting costs away from the maintenance of undifferentiating technology and into advantage-creating innovation. That's also a blogworthy point.

And the list just kept on going, with #3 through #6 being

• Strategic response to the economic situation
• Emphasis on the business role of the CIO
• Assessment of cloud computing
• Adoption of SaaS in more diverse organizations and roles

In courtesy to IWeek's Bob Evans, I won't quote all six items here but will instead urge you to have a look at his list (linked above) -- especially his top six points for the imminent '09.

Over on eWEEK.com, commentator Rich Milgram has offered a list of Four Tips for IT Career Survival during the current economic turmoil. Reading the list, it sounded to me like Four Reasons to Get Serious About SaaS/PaaS.

Tip #1:  Provide meaningful results

The rapid time to value of SaaS/PaaS solutions, and the tight feedback loop that they enable between user requests and prompt modifications and improvements, dramatically raise the profile of the IT professional as a valuable contributor.

Tip #2:  Step outside the comfort zone

People often ask me if SaaS/PaaS adoption is a precursor to outsourcing and IT force reduction. My feeling is that an IT department that's administering a basement full of commodity technology is a prime candidate for outsourcing, but a staff of business process engineers who are vigorously engaged with unit managers and other stakeholders are far less likely to be replaced by contractors or generic service providers. Yes, this means learning new vocabularies and adopting new points of view. Do it.

Tip #3:  Take advantage of learning opportunities

I'm perplexed by the Stockholm Syndrome that seems to make developers more comfortable with tolerating the pain that they know than they are with the idea of learning how to escape it.  There's never been greater access to free materials and experimental learning environments.  Core skills never become obsolete, but new skills are important to maintain any professional's value.

Tip #4:  Plan for the best, yet prepare for the worst

SaaS/PaaS development lets an organization build the systems that it will want to have in place, fully baked, when business conditions improve. The subsequent scale-up can proceed far more rapidly with SaaS/PaaS than with previous generations of technology.

I'm not saying that any of us are going to enjoy the next few years, but let's engage the opportunities that they present -- instead of hunkering down, and merely hoping we'll still be here when the upturn arrives.

From Bangalore last week, I sent my three sons a note that included the warning: "You'd better plan a career path that puts you in a position to write the specifications, because you don't want to be competing against these guys for the job of writing the code."

I was there to lead two sessions at the opening two-day meeting of the Business Technology Summit, plus another session at the half-day companion event in Mumbai two days later. While traveling to the Bangalore conference, I got a double-barreled reality check on the vigor of the technology marketplace where I was going to speak.

• First, I saw a story about the intensely entrepreneurial spirit of software development in India;
• Second, I saw a story about the launch of Intel's latest 6-core Xeon, primarily (and for the first time) a design product of that company's Bangalore center.

At all of my three presentation sessions, the audience lived up to the image those news stories suggested. I was asked to discuss potential business plans for new startups, and to share my research on cloud computing security and integration opportunities. The energy and intensity of those conversations were matched only by the enthusiasm I encountered for the competitive possibilities and the economic incentives of Platform as a Service.

India's projected to be a booming market for PaaS, with growth rates far exceeding those of the U.S. and Europe -- perhaps even edging out the rest of the fast-growing Asia-Pacific technology arena. That's great news for India, but definitely also a challenge to developers in the rest of the world.

If you have not yet downloaded Google's Chrome browser -- sorry, as of now only offered in beta for Windows XP and Vista -- then I urge you to make the time. My initial reactions are that it's enough like Firefox to be familiar, sufficiently improved over Firefox to be worth the effort of migration, and sufficiently faster at many tasks that it's likely to become my default tool -- on Windows -- for anything more than simple browsing.

Until I can launch Chrome on Mac OS X, and until it's also available for Linux, I have to keep a leash on my enthusiasm: a Windows-only browser is a technology demo, not a way of life. That said, Chrome bids fair to serve as existence proof for some lifestyle choices that I'd like to have the option of making.