May 13, 2004

Book Review: The Social Life of Information

I just finished reading The Social Life of Information, by John Seeley Brown and Paul Duguid. This was not the quickest read; it's a business book with the obtuseness of vocabulary that implies. However, if you're a computer person with any desire to see your work in a larger context, this is a book you should read. In it, they examine eight separate areas in which computers, and the internet in particular, have supposedly changed our lives (this is typically called 'hype', though the authors don't use the word) in the latter years of the 20th century. (This book is copyright 2000.) You probably remember some of these claims: the death of the corporation, of the university, of paper documents, of the corporate office. In each chapter, they review one claim, show how the claim's proponents over-simplify the issue, and look at the (new and old) responses of people and institutions to the problem that the claim was trying to solve. They also examine, in detail, the ways in which humans process information, and how the software that is often touted as a replacement simply isn't.

I really enjoy 'ah-ha' moments; these are times where I look back at my experiences in a new light, thanks to a theory that justifies or explains something that I didn't understand. For example, I remember when I started my first professional job, right out of college, I thought the whole point of work was to, well, work. So I sat in my cube and worked 8 solid hours a day. After a few months, when I still didn't know anyone at the office, but had to ask someone how to modify a script I was working on, I learned the value of social interaction at the office. (Actually, I was so clueless, I had to ask someone to find the appropriate someone to ask.) While examining the concept of the home office, the authors state "[t]he office social system plays a major part in keeping tools (and people) up and running." It's not just work that happens at the office--there's collaboration and informal learning.

I've worked remotely in the past year for the first time, and anyone who's worked remotely has experienced a moment of frustration when trying to explain something and wished they were just "there," to show rather than tell--the authors refer to this process as 'huddling.' When someone is changing a software configuration that I'm not intimately familiar, it's much easier to judge correct options and settings if I'm there. The authors explain that "[huddling] is often a way of getting things done through collaboration. At home with frail and fickle technologies and unlimited configurations, people paradoxically may need to huddle even more, but can't." This collaboration is even more important between peers.

Reading about the home office and its lack of informal networks (which do occur around the corporate office) really drove home the social nature of work. After a few years at my company, I had cross-departmental relationships (often struck up over beer Friday) that truly eased some of my pain. Often, knowing who to ask a question is more important than knowing the answer to the question. It's not impossible to build those relationships when you're working remotely, but it's much more difficult.

Another enjoyable moment of clarity arose when the authors discussed the nature of documents. I think of a document as a Word file, or perhaps a set of printed out pages. The explicit information (words, diagrams, etc) that I can get from the document is the focus (and this is certainly the case in document management systems sales pitches). But there's a lot more to a document. How do I know how much to trust the information? Well, if it's on a website somewhere, that's a fair bit sketchier than if it's in the newspaper, which is in turn less trustworthy than if I've experienced the information myself. Documents validate information--we've all picked up a book, hefted it, examined it, and judged it based on its cover. The authors say "readers look beyond the information in documents. ... The investment evident in a document's material content is often a good indicator of the investment in its informational content." Just as if someone says "trust me" you should probably run the other way, information alone can't attest to its own veracity. The authors also look at aspects to documents (like history, like feel, like layout) that simply aren't captured when you treat them as streams of bits.

And there are many other examples of 'hype' that are deflated in this book, and a few other 'ah-ha' moments as well. As I stated above, this is a great read for anyone who thinks there is a technical answer to any problem (or even most problems). By taking apart various claims, and examining the truth and untruth of those claims in a real world context, these two authors give technology credit where it's due, while at the same time explaining why some of the older institutions and important factors in our lives will remain around. Reading this book was hard work, but understanding what the authors say gives me yet another way to relate to non-technical people, as well as fend off the zealots who claim, in a knee-jerk fashion, that more software solves problems. I majored in physics, in college, but minored in politics. It always seemed that the people problems, though more squishy, were more interesting. This book is confirmation of that fact.

Posted by moore at May 13, 2004 02:20 PM | TrackBack
Comments

three thoughts:

1) does the book say anything about working in an office environment where huddling doesn't occur? this happened at comcast, and to some extent it happens where i am now. after my experiences at XOR, it's very hard for me to adapt. coworkers are no more than their job descriptions, and "human moments" are few and far between, even among team members.

2) as i work with the developers to integrate their applications into the new web site, i often find myself explaining why their perfectly rational technical solution won't work when our intended audience has to use it. sometimes it can be just as hard translating a non-technical user-interface need into something a developer can understand as it is to translate "programese" into English. glad to see somebody pointing this out.

3) i want to believe your book review and add this to my book list, but i'm still struggling through "The Sparrow." i place some of the blame on Dan Brown - he caused me to develop attention deficit reading disorder. do you think there's a cliff notes version of "The Social Life of Information"?

Posted by: nancy at May 13, 2004 09:07 PM | Permalink

Hi Nancy,

Thanks for your thoughts. Three thoughts in return:

1) Re: the dysfunctional workplace: I don't think the authors speak directly to this subject, but they do talk about re-engineering--the process oriented cure-all of the 1990s. I think that they touch on the need for peer communication in that chapter, if only to discuss how re-engineering (and all process oriented solutions) ignore that.

2) I imagine that engineers who build cars have to deal with much the same issues as developers who build business applications; both types of techies are so involved in the product that they can't see the forest for the trees. Translation will always be difficult (and your skills always needed!), I'm afraid. I think it's a thought process thing.

3) I can't believe you're struggling through "The Sparrow." I can't put that book down to save my life--every time I pick it up I end up re-reading it. But to the point, there's no Cliff Notes version of this book that I know of, but some of the chapters are available online, here: http://www.slofi.com/toc.htm. If you want an idea of the major themes behind the book, read chapter one.

Posted by: Dan Moore at May 13, 2004 09:27 PM | Permalink
© Moore Consulting, 2003-2006