Tools vs. practice

Jim McGee wrote a great piece on tools and practices. He argues that the ease of getting started with the first 5% is deceptive.

“We focus on the details of particular features and functions at the expense of ignoring the cognitive challenges of deep thought and collaborative work.”

I think it is important that we distinguish between “deep thought and collaborative work”. Tools for these two coincide only for roughly 5%.

It is useful, though, to recall that these 5% did have their merit. Almost 10 years ago, I wrote for my users (in German, here,) “What does my personal productivity have to do with ‘social’ software tools? … users use the same tools [for both].” (In particular, social bookmarks and annotations thrived because they were selfishly provided but were useful to others, and on the other hand, blogs and wikis often served also as notes to self.)

Also, I would like to defend the ease of getting started. Trying out a new tool is a risky investment of time. But there is no way of evaluating a think tool without personally trying it out. The closer it is to the mind, the more it can be compared to a tight garment which must perfectly fit.

For ‘deep thinking’, tools need to be more than just logistics (storage and transport) of thoughts. (In his recent blog post on Intelligence Augmentation, Clark Quinn tackled the tight integration of the ‘cognitive and computational architectures’ by carefully carving out some aspects of what the latter can do well — details, repetition, find correlations.)

Now for collaboration, the ‘tight garment’ cannot fit multiple persons simultaneously. A sad practice is often that the group settles on the least common denominator (email) because a stubborn member (the boss?) refuses to try out a better way.

Here it is useful to distinguish between passive acceptance/ refusal, and active choice of one’s pet function. And then apply Postel’s Principle: “Be conservative in what you send, be liberal in what you accept“. For example, messages without subject line or with the repeated, misleading subject line, are read but should still be avoided. The trick is then to try out what range of choices are tolerable for everyone to accept — not only which features optimally cater to individual expressiveness.

In practice, important examples of differing tastes are: How much should be sent across ‘push’ channels as opposed to ‘pull’ channels, or: where is more divergent information appropriate and where should convergent contributions prevail. Often, the intervention of a stout-hearted but gentle personality such as the ‘wiki gardener’ is needed. So, to answer Jim’s question “Where are good places to look?“: in gardening 🙂 His guess, software development, does not sound too promising to me — despite the GitHub workflow appears like magic — because tt requires more discipline than is usually accepted.

This entry was posted in Knowledge management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s