Subscribe to this blog in Radio:
E-mail this blog's author, Scott Rosenberg:  |
|
The Wikipedia's heavy metal umlaut page is a pretty amazing thing in itself. But this is even more amazing.
Jon Udell has been pioneering what he calls "screencasting," an unusual sort of online journalism that involves taking over your browser screen with screengrabs and animations while he narrates via the audio track. It always seemed mildly interesting to me as a way to do technology demos and product walkthroughs and the like; but with this piece, Udell has taken the form to a higher level, and shown us that it's something weird and wonderful -- and unique to our new Web world.
Plus we get a full technical education in the difficulty of producing an umlauted "n" on screen, an investigation into an act of drive-by wiki vandalism, and an anthropological chronicle of the behavior of Wikipedia contributors. Bravo!
|
|
I've been following some of the coverage of the Blog Credibility Conference at Harvard (from, Weinberger, Jarvis and Winer, among others). It continues to amaze me how much of this debate is a retread of the mid-'90s, when journalists first moved online and discovered that the Web moved really fast, had different norms, gave their readers new voices and made their own voices sound stuffy and institutional. First I think, "Come on already!"; then I think, "Oh, it's okay." Lessons that change one's professional habits need to be learned from experience, and a much wider population of journalists is being exposed to these changes now that blogging software has drastically expanded the universe of personal media.
This post by David Weinberger puts some of this in a smart perspective -- focusing, as I and many others often will, on the critical fact that the vast majority of blogs (like the vast majority of the Web itself) represents stuff created not to "aggregate eyeballs," build traffic, produce revenue, compete with the pros or otherwise challenge or replace the existing order of the media. People are building something fundamentally new, something that had no opportunity to exist before, and that will -- as all such new developments in media do -- end up changing but not replacing what's already here.
There's another disconnection between the "we're-changing-everything" bloggers and those newsroom veterans who don't understand what the fuss is about, and it has to do with scales of time. If you run a newspaper or a TV news operation you have spent your whole professional life in a stable structure, one whose supporting beams of business and technology have never fundamentally shaken or broken under you. The world of professional media has experienced such changes only across the span of a century. But the world of the technology business experiences big changes on a scale of decades -- an order of ten faster. Dominant companies rise and fall, new technologies change the rules of the game, and habits of doing business get tossed in the trash every 10-20 years instead of every 100-200 years.
As a lifelong professional journalist who jumped headfirst into the tech-industry world a decade ago, I've made my choice. I don't see getting anywhere by putting one's money on the idea that change in this field is going to slow down rather than speed up. Which means that, if I were sitting in a newsroom today, I might think it prudent to listen a little less to the voice that says, "Who are these upstarts telling me what's wrong with my work?" -- and a little more to the one that says, "Wouldn't it be fun to do things differently?"
|
|
On today's New York Times op-ed page, Nicholas Carr of "Does IT Matter?" puts the FBI software meltdown in the context of other recent enterprise-scale software train wrecks like McDonald's Innovate and Ford's Everest (he could have dragged in the IRS, too). As everyone does who addresses this topic, he references the Standish Group "Chaos" report from 1994, with its dire statistics about software failure.
As with his previous arguments on the topic, Carr gets things just about half right: Of course the record of large-scale software projects, particularly those meant to replace existing systems that are functional but graying, has been awful, and the complexity of these systems remains daunting. Carr concludes that the complexity is so overwhelming we should give up on innovating in software and just concentrate on doing the same things we currently do more efficiently: "When it comes to developing software today, innovation should be a last resort, not a first instinct."
He's forgetting that, in the world of software, innovation is the primary way to add value. We move existing "off-line" systems and processes into software not only to make them more efficient, but to give them capabilities the physical world can't provide. Thus online publishing isn't just about delivering text and images more cheaply; it's about connecting publisher and information consumer in new ways that change the whole relationship. Manufacturers implement inventory control systems not just to save money but to transform their businesses so they can build products when customers ask for them, rather than trying to guess what the market needs. If software isn't providing new capabilities, why bother? It seems obvious that we're a long way away from exhausting the possible new wrinkles software can offer business, government and society.
Carr is right that large institutions get into trouble when they try to replace big old systems and introduce complex new features at the same time. But his advice -- give up on those new features, be happy with what you've got -- is needlessly ostrich-like. The answer is not to abandon change but to structure change so that it's not a big bang but an evolutionary process. The failures in so many of these software disasters don't stem from ambition but from impatience and bad planning.
|
|
|
