it has come to this.

90 in 90. Um, well, not really.

So,  hi there.   Been a while, huh?

Admittedly, I did not keep up with the 90 in 90 project for the full 90 days.   While this might look like a failure on the surface, I must say that the exercise was a huge success for me.   When I started the experiment, I was in a bit of a creative rut, more tied up with project administration than doing anything creative or novel.   After just a few days of carving out some daily time to reflect on different approaches to a tough problem, I found that I was able to start to climb out of that ditch.   I went from living in budgets and email to working on several new approaches to problems we face on the project.

Maybe 90 days was too ambitious, but setting aside some time for regular creative practice was a great catalyst for refocusing effort on new and novel projects.   If 90 in 90 was a failure, it was only because it got me passionately working on small projects that couldn’t be fully articulated or completed in a single day.

I’ll take that kind of failure any time.

17/90: Away.

Like many people, I find that my widespread use of collaboration and communication technologies makes it possible for my work life and its demands to find me almost anywhere and any time on the globe.   This makes it almost impossible for me to really get away, meaning that I miss out on a lot of the restorative benefits of time off.   Even more problematic is that I find that some of my best ideas and best work come as I’m truly unplugged or shortly thereafter.   In short, my current uses of collaboration technology let me stay engaged with work, all the time, for better or for worse.

I really want the Away application.   Given that getting away from it all can be hugely beneficial, I think that there is an opportunity to develop  a system that filters out, evades and distracts from the distractions of work relentlessly.   Such an application, might provide video and audio feeds of real and far away places (not simply video loops) and actively prevent all but the most urgent messages from showing up.

For this to succeed requires a much better understanding of relaxation.   It is easy to interrupt relaxation with work, but I think more challenging to preempt work with relaxation.   If we could figure this out, however, the benefits would be huge.  Rather than burning down psychic reserves, technology could help provide a retreat mechanism for reflection and rejuvenation.

16/90: Failure multipliers

We often take reliability for granted since the published MTBF numbers for vulnerable pieces of hardware tend to be quite high.   Given that the a component is likely to fail every 6.5 years, we should generally be good.  Right?

Systems for remote collaboration, however, are a place where failure gets multiplied.  Since these systems often consist of networks of components, that are connected to communication networks that send traffic to other networks of components, the reliability of the overall system quickly drops far below the reliability of any individual component.

In order to better understand system reliability, I’m experimenting with diagramming a complete end-to-end system as a network and attempting to make some reliability judgement about each component.    If nothing else, a network-based representation of a distributed system may help articulate the vast number of threats to system reliability, which range from a component failing to a power outage at a given location.   I’ll add diagrams to this post when they are finished.

15/90: Where was I?

In addition to remote collaboration, one of my core interests is measurement.   Personally, I’m drawnt to tools that automatically log data about my life and I keep a log of about 20 factors related to my health and quality of life.   Yes, I realize this makes me a little crazy.

Anyway,  as I was sitting in a meeting today, reading a paper written by someone living 2,000 miles away and answering questions from a student that lives 250 miles away over IM, I was struck by how complicated presence has gotten.   I’m interested in coming up with a way that we I can record and examine the correlation between physical presence and attentional presence.   For instance, though I was physically present in a meeting, my aggregated presence probably put me somewhere in Iowa, given the geographies that I was divided between.   Looking at both trends in aggregate presence and cases where physical and attentional presence diverge, I wonder what kind of design opportunities can arise.

14/90: Spheres of influence

Recently, I had a very good meeting with someone who was actively looking for people doing work similar to what I do at my institution.   This individual was towards the end of his search, and only found out about me because a colleague at an institution 2000 miles away talked about my work in a recent conference keynote.

This experience highlighted the role distance can play on the salience of information.   Distance seems to weaken ties, causing the information that flows across those weak ties to seem all the more important.   Among the locals, the work I’m doing was totally lost in the noise; there are simply too many good things going on to keep track of.   However, the project in question was relevant enough that it was carried across the weakened tied, causing it to be rediscovered by the person conducting the local investigation.

This experience makes me wonder if there are other advantages/implications for expertise location in geographically distributed networks.  In this case, the fact that my project achieved some sort of ‘escape velocity’ caused it to be discovered by an organizational insider when it was introduced by an outsider.   In one way, distance introduced a process of reflection that both selected and validated work being done locally.   How can this be systematically leveraged to apply external filters to information that might otherwise be buried by organizational biases?

12/90: Snakebit

2009 has not been a particularly lucky year for me so far.   In particular, the demo gods are frowning upon me through very poor equipment reliability.   On quick count, I’ve had at least 8 pieces of hardware fail independently in the past month or so.  Different manufacturers, in different buildings, doing different things.  No real common element.  Just bad luck, it appears.

If you look at the odds, this means that I will likely not have another piece of equipment fail for the rest of my life, but I’m not that optimistic.   In many cases, the failures have been problematic and not particularly instructive - things failing at bad times and without sufficient time to replace with a spare.  Mind you, we are prepared.  We have spares of critical components.   There just hasn’t been enough time between failure and showtime in many cases to recover gracefully.

In the context of the 90in90 project, I’m struggling to figure out how to learn from this.   Given that the effects of failure grow in collaborative systems, how do we design and build high-reliability solutions without complete overkill?  How can we stage parts throughout a physical plant to minimize recover time (well, okay, this is probably a big and well-studied logistics problem)?  Moreover, when things fail, how can we support honest and reasonable dialog between a system and its users about the cause of failure and its implications for longer term trust of a system?