Category: Tech

Identification — on or off?

Jon Udell contends that we’re hard-wired to recognize other humans:

Humans are hardwired to recognize faces, voices, gaits. We do it always and automatically. Perhaps so automatically that we don’t notice, for the most part, that we are doing it. When my teenage daughter comes downstairs there’s rarely any ambiguity about who she is.

Jon is disagreeing with David Weinberger, who says that identification defaults to off:

In the real world, we don’t identify everyone. We only identify those about whom we have doubts that we have to resolve for some purpose. Identifying is not the default in the real world. Nor, IMO, should it be online.

They’re both right. We instinctively recognize other people — nod to neighbors, chitchat with baristas, and identify those we know well by the smallest of gestures.
But we don’t ask for deep ID until its necessary. The social protocol for data is progressive disclosure. When do you learn someone’s street address? Their home town? Their salary? The default is to start shallow, and to get deeper with trust.
Computers are literal-minded critters. Knowing hair color and HIV status is all the same to them.
Perhaps identification defaults to on, but disclosure defaults to off.

The Raymond Rule

“Only at grave peril shall you ask a question for which there already exists an answer somewhere in the world.” This principle drives me batty, and causes geeks to waste hours of time. It’s the macho-geek version of guys refusing to ask directions and driving till they are hopelessly lost.
Erik Raymond wrote the canonical explanation in How To Ask Questions. The geek world is run by wizards who don’t have time to answer newbie questions and keep the earth orbiting the sun.
Therefore, if you have a question, you must read the man pages, scour google for diagnostic phrases, spelunk through code, and test your hypothesis. If you still haven’t found the answer to your question after two hours, three hours, eight hours… then you may ask the wizard who may know the answer off the top of his head.
Otherwise, you risk scathing criticism, and a permanent deduction of 20 points from your interlocutor’s estimate of your IQ.
I’m really glad to see LinuxChix which looks like it provides a forum for improving one’s tech skills without facing the consequences of the Raymond Rule.

Technical support by RSS

Last week I was scanning my RSS reader and stumbled across a Socialtext bug report. The Shifted Librarian wanted to scan the RSS Winterfest weblogs, and ran into a bug in our new RSS feed. I reported the bug. Pete diagnosed the problem in the blog comments.
RSS for information discovery, and weblog for collaboration. It works.

RSS Attention Management

RSS readers are very handy for people to manage attention to incoming information.
Debates about the relative superiority of RSS readers and web browsers are missing the point. Nobody wants the whole web coming to their desktop reader.
You use RSS for sources that change periodically, that you visit again and again. Bug-tracking is a great application — several people in the RSS-Winterfest IRC mentioned bug-tracking as handy use of RSS.
A few people in the IRC mentioned RSS for alerting. The RSS polling design isn’t intended for real-time notification. For that you need IM or Jabber or Tibco. Real-time notification and periodic updates can be used nicely side-by-side — for example, a system administrator might want routine human and system notifications via RSS, and system-down or danger-zone alerts by IM or pager.
Information updates have different levels of urgency — “the building is on fire” is more urgent than “the room temperature has increased from 68 to 72 degrees” (unless you’re managing a temperature-sensitive lab culture).
A given piece of information is more urgent for some than others. A customer support query is urgent for the service reps on duty, and of background interest to product managers and developers.
We need a range of attention-getting media.
* IM/pager for lapel-grabbing alerts
* email for important, short-notice items
* RSS for alerts for discretionary attention
* Weblogs and wiki providing a “browse mode” fix for recent changes junkies, and a searchable archive for occasional readers
(We also need a Ross Mayfield trademark colorful chart to gain fame for the concept.)
These modes complement each other. They help individuals manage attention, and they help organizations focus attention on urgent matters, while building knowledge in important areas.

RSS-Winterfest — the liveliest teleconference ever

Over 1000 participants participated in the RSS Winterfest voice-blog-wiki-IRC multi-model conference last week. Socialtext hosted the “Eventspace” wiki-blog — we hosted the application, and we also helped to host the online party. It was lots of fun, included insightful conversation, and created useful resources.
Participants in IRC improvised conversation on the themes of the sessions. Bloggers posted session notes and questions and resources. Wiki participants built collaborative pages on RSS Tools, RSS Authentication, and other topics.
Here are some of the practices we used that helped make the conference lively:
* create weblogs with relevant topics
* set up sign-in space for people to describe themselves and learn about each other
* pre-populate the wiki with the conference program and other resources
* real-time gardening — link interesting pages to the home page, consolidate related resource pages, help harvest quotes and references.
Maybe most important, we helped weave questions, comments, and insights from the IRC and wikiblog into the voice conference. It’s a salon facilitation skill, translated to electronic media.
This RoperASW/Tandberg polllast year revealed the crushing tedium of traditional teleconference. Less than half of attendees actually pay attention to conference calls. With audience participation tools, you get an event that is more lively and intelligent.

Is RSS Ready for Prime-Time

Dylan Greene writes an insightful yet ultimately unsatisfying piece arguing that RSS is not yet ready for Prime Time.
He’s right that RSS has weaknesses. The way most people use it, it wastes bandwidth. Many feeds don’t include full-text (need to fix this…). Comments aren’t well integrated. And, the coup de grace, an RSS reader isn’t yet built into Microsoft Windows.
True, but not that useful, unless you’re a Gartner analyst trying to determine whether a technology has reached a state of ultimate, top-right-quadrant maturity.
The interesting questions are:
* is RSS mature enough to do what you want?
* can you benefit from RSS as an individual, a publisher, or an organization.
If you’re a mildly tech-savvy individual wanting to keep track of lots of weblogs and news, then RSS is a lifesaver.
If you’re a complete novice, or if you advise complete novices, you probably want to avoid RSS — though bloglines is pretty darn accessible — I’d recommend it to anyone who is comfortable with a browser.
If you’re a blogger or web publisher, and want to reach the increasing number of users who depend on RSS to read web content, then surely publish in RSS.
If you’re in an organization where most people are drowning in email (i.e. most of us) and you have influence over technology choices, you might want to consider using RSS to complement business applications, helping individual employees manage their time and attention.
Dylan’s points are correct, but they don’t tell you whether the rewards of RSS are worth the trouble for you. It takes a bit more effort to use technologies that are somewhat in their life cycle. You need to decide whether it’s worth it.
If you’re an open source geek or work for a technology company that’s not Microsoft, you have opportunities to shape next-generation syndication standards and applications. Those opportunities are here now, and will be gone in a few years.

Open source informalism

UC Irvine Researcher Walt Scacci is studying open source development, and has come across distinct practices.
It’s not clear to me how the open source practices differ from agile processes in general — a lighter, more conversational, less document-heavy design process.
What are some of the differences you’ve found, apart from the obvious ones?

For example, in software engineering, there’s a widespread view that it’s necessary to elicit and capture the requirement specifications of the system to be developed so that once implemented, it’s possible to pose questions as to what was implemented, compared with what was specified.

We do not see or observe or find in open-source projects any online documents that software engineers would identify as a software requirements specification. That poses the question: What problem are they solving, if they haven’t written down the problem? While it’s true that there’s no requirements specification, what there is instead is what we’ve identified as a variety of software informalisms.

What do you mean by “informalism”?

That word is chosen to help compare to the practice advocated in software engineering, in which one creates a formal systems specification or design that might be delivered to the customer. Informalisms are such things as information posted on a Web page, a threaded e-mail discussion or a set of comments in source code in a project repository. It may be a set of how-tos or FAQs on how to get things accomplished. Each is a carrier of fragments of what the requirements for the system are going to be.

Simplicity is hard

In the article about the 80/20 rule, Tim Bray explains that simplicity isn’t easy.
In Tim’s words, “the mental machinery involved in the design process naturally tends towards more rather than less.”
The unofficial version of my business card reads “grinch.” I spend a lot of time saying no to all kinds of attractive, bright, shiny jingly ideas. “Too complicated.” “Not the most important thing right now, maybe later.” “What’s the simplest way of doing things that works”? Two parts diplomacy, one part curmudgeon. Not a good way to win popularity contests.
Before Christmas, from a biotech company, “This is much easier to use and manage than $competitive product. I can use this with much more of my team”
Yesterday, from a consultant who helps organizations improve collaboration and manage knowledge… “It’s like $competitiveproduct, but easier to use and cheaper.”

The 80/20 rule wins

Tim Bray has been working on a series of articles analyzing which factors lead to technology success. The strongest predictor isn’t investor support, technical elegance, a compelling idea, standardization. It’s the “80/20” rule, systems that yield 80 percent of the benefit for doing twenty percent of the work.

The 80/20 Tribe