A Review of Social Thinking–Software Practice
As someone who has taught many types and levels of writing courses, I've become quite accustomed to the first-week ritual of pointing out to students that they can become valuable and active contributors to virtually any of the myriad of intellectual, cultural, and social conversations they will encounter as college students. The process seems to get a bit easier each semester. In fact, I thought I had it all mastered. But then I picked up Social Thinking–Software Practice. The book is a collection of position papers from a 1999 conference in Schloss Dagstuh, Germany. The book contains 21 essays discussing software development, design, and use. Further, it examines the often fractious relationship between software developers and engineers, is concerned with designing and refining software programs, and studies ways that functioning software can be made more usable. The essays take different approaches in advocating more active inclusion by software developers of social scientists in the software design process. After all, the authors argue, software is as much about the people who use it as the ones who create it.Yvonne Dittrich, Christiane Floyd, and Ralf Klischewski, eds.
Cambridge: MIT Press, 2002
ISBN 0-262-04204-5 $55.00 pp. 493
Review by Tracy Clark
Purdue University
As I scanned the Table of Contents, my thoughts immediately traveled to an oft-quoted statement from Kenneth Burke's Philosophy of Literary Form about joining conversations: "Imagine that you enter a parlor. You come late. When you arrive, others have long preceded you and they are engaged in a heated discussion, a discussion too heated for them to pause and tell you exactly what it is about." What contributions could I possibly make to a conversation in which the dialogic community appears so insular, and the subject matter is so completely over my head? This thought was soon replaced by: "This stuff doesn't really have much to do with me, or with anything going on in my life." I closed the book, deciding that I could always incorporate into the upcoming semester's writing courses this unnerving experience of feeling completely shut out of a conversation.
A month or so later, after enduring a sense of failure stemming from being a college English teacher who couldn't get past the Table of Contents, I made myself pick up the book again and resolved to find a way into this conversation. Like other teachers of writing in computer-mediated environments, I'm especially interested in finding ways to incorporate technology into the writing process that further course objectives while meeting the needs of diverse groups of students. And while I haven't had much occasion to think about the ins and outs of programming–except in the context of "Is it possible to develop software that's both loaded with features and easy to use?"–I am interested in the social and intellectual implications associated with our increasing reliance on campus-administered technology infrastructures for even the most incidental of classroom activities. Here was my way into the book!
The
book
The editors use the introduction
to discuss how the book came into being, and to briefly define and
contextualize its five sections: Deconstructing, Informing, Grounding,
Organizing, and Reorienting. They present a problem that most of us have
encountered in some fashion: the often conflicting priorities of software
programmers, social scientists, and end users make it difficult to reach common goals. We seek the design and implementation of powerful, yet usable, software
suitable for business, industry, education, the arts, services, and the home.
The editors, as well as the authors whose works they have included, advocate
approaches of innovation, negotiation, collaboration, and cooperation in an
attempt to better realize the overwhelming power and potential that software,
its design, its implementation, and its use afford all of us. We're told that
the book is geared for a number of different audiences, ranging from software
programmers and researchers to social scientists to teachers. With such a wide
readership in mind, the authors invite us to use the book's larger
organization, as well as individual chapters, in order to pick and choose
what's most useful. In other words, we don't have to read the whole book. Nor do we necessarily need to read chapters in sequence.
In the "Deconstructing" section,
authors present articles in which they trace the multiple and overlapping
relationships between programmers and social scientists. Christiane Floyd uses
the first chapter to establish a definition of social thinking and software
practice that governs the book as a whole; she also describes what she calls
"computing" as necessarily concerned with both development and use by "actors"–programmers, designers, social scientists, and end users (6)–of
"computing artifacts," or "agents" (7). This further establishment of the
book's framework leads us into the second chapter, in which James M. Nyce and
Gail Bader discuss their ethnographic projects involving high school teachers
incorporating a widely-available multimedia project on American history. In
keeping with this section's emphasis on parsing the relationship between
social thinking and software practice, Nyce and Bader reflect on their work
not in terms of the teachers who incorporate the project or the students
who learn from it, but from the perspective of its creators who implemented
Scandinavian-influenced participatory design measures. Subsequent chapters in
this section discuss, respectively, obstacles to incorporation of social
science methods in software development and a critical observation of the
relationship between software developers as individuals and end users as
software practitioners.
The "Informing" section leads off
with another consideration of the role of ethnography in social thinking and
software practice. Chris Westrup uses his essay first to present ethnography
as a viable route toward the development of powerful, usable software, and
then to examine theoretical discussions related to the study and practice of
ethnography. Such an approach is surprising here because we more often discuss
the theoretical and then use it to achieve a thoughtful, sustained discussion
of the practical–and because the book as a whole is built upon the "theory
first, practice later" model. The next two essays in this section continue the
thread of ethnography by presenting specific projects. Finally, Eevi E. Beck
presents a graceful discussion of the relationship between "seeing" and
"looking" in her essay on researching theories and practices of
method.
"Grounding," as Yvonne Dittrich
tells us in her introduction to this third section of the book, is necessary
in order for us to fully evaluate and apply the relationship between social
thinking and software practice (181). She argues that while participatory
design approaches and other user-centered methods have increased usefulness of
software programs, we should be careful not to diminish overall usability by
proportionately diminishing the role of software programmers and engineers.
Chapters in this section present frameworks for implementing social thinking
into software practice and more case studies.
The fourth section, "Organizing,"
contains essays discussing ways in which social thinking and software practice
ideas discussed in the first three sections can be implemented in various
workplaces: software manufacturers, businesses and industries who must decide
whether to develop their own technological infrastructures or buy
already-produced software, and universities and other research institutions.
Especially useful here is the fourth of five articles, as it
presents a study of three work environments in which work is done by off-site
contract employees, with no physically-established workplace, little
direction, and little supervision/feedback. This discussion, carried out
through presentation and critique of work environments with limited and
haphazard organization, illustrates the necessity of organization through
mutual cooperation between developers, social scientists, managers, and
employees/independent contractors.
Finally, the fifth section is
devoted to "Reorienting," a concept Olav W. Bertelsen describes as the process of considering
answers to the the question of "How should social practice be expressed in
software thinking?" (387). The four chapters in this section look at
"useware" design, discontinuities in design, the self and its
relationship with the Internet, and the role of mediation in the useware
process. These chapters, not surprisingly, rely heavily on case study;
nevertheless, they make use of theory and discussion in order to further ideas
and goals presented in earlier sections of the book.
Impressions
Social Thinking–Software
Practice is a daunting read for a number of reasons, most of which have
little to do with subject matter, quality of writing, soundness of argument,
or anything else that can justifiably save or doom a book. These reasons fall
into three broad categories:
- The book represents a distinct, fairly close-knit community in which most of us teachers would not claim membership. Imagine what it would be like for an industry-entrenched software programmer to read a collection of essays penned by recognizable "figures" from the Computers and Writing community. Whether we realize it or not, a portion of our work carries associations that come from meeting people at conferences, working with them at the same school, collaborating with them on projects, or simply seeing their names around. Nuances associated with such long-term relationships are bound to surface in a collaborative work.
- While we have a huge stake in the implementation and/or abandonment of policies described in Social Thinking–Software Practice, we are more interested–and understandably so–in what happens with technology at the end-user/teacher level than we are in the level at which our departments' IT folks are operating. After all, we'll probably need to show our students how to use the Comment function in Microsoft Word for an online peer review exercise before we have to explain similarities and differences between adding background color in Photoshop 5 and doing the same task in Photoshop 6/7.
- Each chapter would be successful as an autonomous essay–but the articles derive enough of their structure and content from one another, from their placement within the book, and from the book as a whole that we really do need to read the entire book, and read each article sequentially in the process. For example, not only do authors in later chapters refer to material discussed in earlier chapters, but also they use acronyms for concepts that are both defined and spelled out for us in those earlier chapters.
The rest of the book follows in similar fashion, as authors devote the introduction and conclusion sections to presenting structures and reiterating key points, and use the middle of their essays to present examples, analyses, and connections. The prose, as a whole, is clear, accessible, and interesting. Readers who have little familiarity with social thinking and its relationship with software practice, or vice versa, will get up to speed fairly quickly; however, there's still plenty enough "stuff" for readers who do have experience with one or more of the theories or practices discussed in the book. And while nothing earth-shatteringly "new" is presented, we are reminded through insightful discussion and varied presentation of case study that awareness of the negotiation of differences among programmers and social scientists, in the backdrop of their common goal of facilitating software development and use, is important to all of us.
Especially notable, when looking at the text from a computers and writing standpoint, are the chapters built upon case studies. They break up a text that otherwise bogs down in the necessary task of laying groundwork for multilayered terminologies, comparisons and contrasts, and explanations of cultural, vocational, academic, and artistic systems for interdisciplinary, international audiences. We become privy to an assortment of workplace collaboration experiments–many of which failed due to conditions such as of imbalances of power and resources between programmers and social scientists, lack of cooperation among one or more constituency groups, hyperorganization in one company and disorganization in the company it attempts to work with, and withdrawal of funding in mid-project. Those of us who incorporate service learning initiatives can learn a great deal from these mishaps. Furthermore, we don't hear about those projects that fail nearly enough.
Unfortunately, Social Thinking–Software Practice errs in many of the same ways in which it excels. While the authors and editors do an admirable job of ensuring that both project and people function as an evenly and carefully integrated group, thriving both on commonalties and on individuals' philosophical and practical differences, they too often forsake forward movement in favor of inclusive, yet circular, discussion. For example, there doesn't seem to be a strong enough distinction between "organizing" and "reorienting" social thinking and software practice. Furthermore, the word "reorienting" suggests a distinct move forward, beyond "organizing." And while the case studies are both illuminating and instructive–and do move us forward to an appreciable extent–they lose their effectiveness as distinct examples of theories and practices at work because there are simply too many of them. One or two more theory- or practice-based, argumentative-style essays included in place of one or two case studies might very well have given this book the actual push forward that it needs in order be more successful as a whole.
These faults aside, Social Thinking–Software Practice has lots to offer, whether we teach freshman composition, technical writing, basic writing, or graduate-level seminars on teaching in the computer-mediated classroom. We would do well to see each of these chapters as opportunities to acquaint ourselves with a set of conversations that, while they might seem "beyond" our realm as teachers and researchers of writing in computer-mediated environments, really are parallel–and more than occasionally both overlapping and intertwined–with our own conversations. Obviously, the decisions made by software developers in concert with software engineers, user testing specialists, social scientists, and network administrators carry huge implications in terms of the work we do with students in our computer-mediated courses and with our own technology-based projects. But more importantly, the ideas presented in this book offer us prime opportunity to adapt, to negotiate, to synthesize, and to learn.
And it is the last of these considerations that is most fruitful here. Social Thinking–Software Practice doesn't read like a book geared toward the Computers and Writing crowd–but that's because it isn't. This book does apply to us, but it serves full-time techies as much as it does teachers and scholars. As we know from working with IT professionals on items ranging from impromptu troubleshooting, to navigating new technology infrastructures, to securing funds for needed software upgrades, initiating and maintaining a dialogue between ourselves and the folks who really make our work possible is vital.
Possessing an understanding of the relationship between programmers, designers, and social scientists–most of which hovers around pre-production issues and therefore "precedes" by several months our acquaintance with a software program–is, for right now, a mark of foresight, something that's "handy." But such familiarity may soon become just as essential as has become the ability to quickly and seamlessly integrate technology practices between PC classrooms with Zip drives and Mac classrooms relying on CD-RW drives and FTP clients.
Recommendations
Social Thinking–Software
Practice is an interdisciplinary text with essays written by, and about,
Western Europeans–particularly Scandinavians–who attended a conference
whose aim was to negotiate the often conflicting needs of software developers
and the social scientists who work with them to ensure user-friendly products.
This distinction is pervasive throughout the book as a whole, and within each
individual essay chapter, to the point that we, as primarily American end
users, might not immediately feel that the book is for us. But once we give
ourselves a chance to recognize and adjust to frames of reference, case
studies, and terminology–often vastly different from those Computers and
Writing (a distinctly American field) signposts many of us have grown
accustomed to–we can much more easily proceed into a text that is, like all
sustainable bodies of intellectual thought, sometimes thought-provoking,
sometimes insightful, sometimes pedestrian.
Indeed, there is a lot here for
readers representing nearly all perspectives, professional and academic
fields, computing proficiencies, and levels of interdependency upon technology
infrastructures. Teachers of technical writing especially will benefit from
discussions of real-life inter- and intra-company relationships, project
planning, implementation of hardware and software, case studies, and
discussion of oral and written reports.
In the introduction, the editors
encourage us to pick and choose from among 21 chapters in order to find
somewhere to begin. This advice is prudent, given the vastly diverse target
readership for the book. It's also a sound example of an introduction that
serves at once as thesis statement and as user's guide. Readers will assuredly
learn a lot from the conversations contained within the book.
So, what
do we do when we walk through that door that is the
cover of Social Thinking–Software Practice, encounter a cornucopia
of in-progress conversations, and realize we have just walked into a gathering
where we know no one, yet everyone seems to know everyone else? Do we traipse
right on in, grab a drink, and wander toward the conversation that seems most
immediately interesting? Do we mill around the fringes, taking everything in
before making a move? Do we perfunctorily circulate before making a graceful,
yet carefully-timed departure? Do we high-tail it out of there? We can make
any and all of these choices; after all, because the conversation that
originally began at a conference has been placed into book form, we can mingle
as we choose.
Those of us who initially bolt in
terror can come back. Besides, the book is so rich with far-reaching
information, debate, and perspective, that even the most initially intrepid of
us will likely view the essays within more as an ongoing chatauqua than as a
one-time address, and therefore stay awhile, leave, return, and begin the
process anew.
Social Thinking–Software Practice
Table
of Contents
| Part
I - Deconstructing Chapter 1 - Developing and Embedding Autooperational Form Chapter 2 - On Foundational Categories in Software DevelopmentChapter 3 - Making Use of Social Thinking: The Challenge of Bridging Activity Systems Chapter 4 - Challenging Traditions of Inquiry in Software Practice Part II - Informing Chapter 6 - Representing and Modeling Collaborative Practices for Systems Development Chapter 8 - What Doesn't Fit: The "Residual Category" as Analytic Resource Part III - Grounding Chapter 10 - Software Practice is Social Practice Chapter 12 - Doing Empirical Research on Software Development: Finding a Path between Understanding, Intervention, and Method Development Part IV - Organizing Chapter 14 - Information Systems Research and Information Systems Practice in a Network of Activities Chapter 16 - Participatory Organizational and Technological Innovation in Fragmented Work Environments Chapter 17 - Large-Scale Requirements Analysis as Heterogeneous Engineering Part V - Reorienting Chapter 19 - Discontinuities Chapter 21 - Intent, Form, and Materiality in the Design of Interaction Technology |