Theory

There was a panel about theory in HCI at the NordiCHI conference today. I wonder what they discussed. It made me think about questions I’ve been asked about the role of theory in human-centered computing, particularly in the context of teaching the Introduction to Human Centered Computing class (which is a survey of a variety of theories about technology). In that class, I recently said something about my own relationship to theory, and now I’m wondering whether it’s true for others, so here goes.

I find some theories more personally compelling than others. They speak a type of truth to me, one that I find very engaging. They bring out, for want of better words, the researcher in me. What I find very useful about this is that because theory is related to methods and questions, I can use these connections to focus in on particular problems. One of the first theories I ever used was Grounded Theory, it’s in my dissertation. I took the route of building more theory atop of articulation work (and to some degree social worlds) to develop my theory of software recomposition. The theory, modestly, explains some of the reasons that software is hard to produce, its because the process of modular decomposition creates a division of labor full of dependencies that are often underspecified and then change during the course of development. All of these dependencies are discovered at integration, unless they are well managed, and that makes production difficult.

Grounded Theory spoke to me. The works I read seemed to address problems that I found compelling, and using methods that I enjoyed to use. It didn’t help me find the domain, that was a different inspiration, one largely stemming from a sense that HCI had overly focused on the end-user taking the engineer to task and I wondered whether the work worlds of developers were as socially and technologically complex as those of the end-users and if so, whether we had to make inroads there in order to make the world of the end-user better. But it did help me formulate questions, operationalize them empirically, and do analysis.

Focus is the enemy of a new researcher. Being reflective on what your passions are might be one way to do this. I’m very lucky I also know the things I do not like to do. I am glad when others do them because I don’t want to.

Well that leaves all the big questions open like what is a theory in HCI, what should it do, what does it mean that we have multiple theoretical approaches, should we develop our own theories or use those developed by other disciplines. But, it is an answer to what problems should I work on? If you can find research that speaks to you very deeply, that supports the answering of questions you find interesting and using methods that you find enjoyable to practice, that seems useful.

Why Theory Matters in Grounded Theory

I’ve written about Grounded Theory before. I’ve written about how its not an excuse to not know what you are doing. This is true of any research of course. I’ve also written about theoretical saturation, in which I commented on the importance of doing the theory development part of Grounded Theory.

Kathy Charmaz’s book reminded me of just how important theory development is in Grounded Theory. She discusses the history of Grounded Theory. At the time when Glaser and Strauss developed Grounded Theory, qualitative research was suffering from its lack of connection to theory. They argued that while many quantitative methods were empirically verifying or exposing problems in existing theory, what Grounded Theory could do was to develop theory. In other words create theory by iterating between data collection and analysis with the goal of converging on a theoretical understanding grounded in the research data.

I took the following away: the reason to use Grounded Theory is to develop a theory. Anything less or else is not Grounded Theory.

There are many reasons to read Charmaz book, but one of them is to understand the contexts in which Grounded Theory emerged. Seems appropriate for an approach that argues that you should pay attention to the data.

The Difference between Theory and Practice

There’s a joke that goes like this

In theory there’s no difference between theory and practice. In practice there is.

I was reminded of this saying, when I read this piece in the New York Times (OK, yes, sometimes I have a backlog of reading).

This is a very strongly worded piece, and I am sure that some people will disagree with it. I find myself resonating with parts of it. That’s not terribly surprising of course. Perhaps what really resonates with me is being careful about separating economic systems from the context that surrounds them. The author says

As I see it, the economics profession went astray because economists, as a group, mistook beauty, clad in impressive-looking mathematics, for truth.

And I reasonate with that because I feel that sometimes this very same thing happens within Computer Science. Sometimes, the human-centered aspects of the discipline are articulated as not being a part of the discipline. I did say sometimes. The author is arguing that human-in-the-loop makes economics more complicated. The financial collapse is a story of humanness in all its forms… it doesn’t mean that understanding the mathematical underpinnings is not valuable, it just means its not enough.

And the same is true of a discipline of Computer Science. The Computer is a human-designed, human-built artifact. The principles upon which is it based, are human-generated (by Computer Scientists). Computers are also human-used, human-consumed. And we use these facts to talk about our solutions. Our visions of what is made possible through scientific and technological innovation in Computer Science are human-motivated. For example, people want to mine, search, and access data, stream video around their house, debug their code, connect their laptops securely to wireless networks, be supported by intelligent machines in office and house work, … the list goes on.

So, I vote for a Computer Science that pursues theory and practice, because they matter equally to our discipline.

OOPSLA becomes SPLASH

OOPSLA is changing it’s name to SPLASH.

Splash stands for Systems, Programming Languages, Applications: Sofware for Humanity. I was very excited when I saw the last two words, and curious.

Unfortunately the SPLASH website does not say much about the choice of name. Reading around I see that there are discussions about how much OO there was left in OOPSLA. But, I wish I knew what cased the last S and H.

I read though that OOPSLA attendance declining. And in another post, Ralph Johnson describes how other conferences will be co-located with OOPSLA (which will remain as a research track). I found the history of Onward! and it’s growth from within OOPSLA to then becoming a stand alone event interesting.

I participate in CHI. Sometimes we talk about the many different tracks as being confusing (for example, does a Work-in-Progress count as a publication, therefore preventing the authors from republishing the work later)? More generally what work do all the different tracks at CHI do? I know that they are hard to organize, so it had better be worth it.

I wish there was more on the OOPSLA change, I can’t help thinking that some of it makes the conference look more like CHI in terms of the variety of tracks. And I would love to know more about the conversations that led the community to decide that this name change was the right thing to do.

Academic Organisation

A colleague of mine, Mark Guzdial has written a thoughtful and thought provoking post on his Computer Science Education blog.

And I was drafting a reply, and I decided that I’d like to write it here.

The gist, as I read it, is that he asks why academic disciplines are organised by outcome rather than by methods. By asking this question you can explore other connections.  In the case of Computer Science Education it turns the focus away from outcomes (measures of learning success, and towards the experiences that will create these desired outcomes, what is the experience of good education).

This got me thinking about what I see as an interesting difference between some of the sciences and others, which has some origins in methods, and theories.

I’ve spent most of my research career as a practicing Computer Scientist. My education is reasonably traditional, and my career has been entirely within institutions focused on the advancement of Computer Science. But, that said, I’ve spent my research career as a user of methods/theories that do not hail from Computer Science, but from Sociology/Anthropology.  And to do that I’ve done my best to learn about the disciplines. And in that journey, I’ve been continuously struck by the volume of debate within those disciplines.

Specifically, I’m struck by how much discussion and difference there is in methodology and theory within both disciplines. My analogy, what would it mean if we had multiple and competing approaches to Computer Science. And I suppose we do. I understand that there are significant philosophical differences within AI. But, I don’t think we teach Computer Science in ways that amplify and centralise those philosophical differences.  I am aware that these differences exist, but I’ve never had a class or seen a book that talks about these philosophical differences and why they exist, and what their origins are.

Are we poorer for that? I increasingly think so…

Another example. I used to be a Software Engineer (which explains why I still review papers for ICSE I suppose, and why I can’t stop subscribing to Software Engineering Notes). So there are a variety of different methods to organizing the work of Software development. Some of the new Agile or Pair-Programming techniques contrast with the Chief-Surgeon model. And while I have read arguments about the differences, and the outcomes and experiences that they make possible (in pair programming people share a machine, so we say that it’s a good way to learn and a good way for the person watching to catch mistakes of the person typing, we argue that that comes with a certain productivity hit because there are half the number of machines in operation, and so we continue…)…

So we have those debates, based on outcomes, and elements of the experience (which we conveniently blur into the debate), but we never really systematically unpack and discuss the many different ways that work can be divided. (My first advisor Rob Kling told me never to use the word organization as a noun—it was a convenient gloss over the vast array of organizational types—I think he’s right). Organization is a verb, and it is the division of labor and the assumptions that frame that particular set of institutional arrangements.

And I think in disciplines where there is lots of debate about the philosophical nature of the world, there’s far more explicit discussion of the theories and methods and their explanatory power as it relates to that particular set of philosophical commitments. I think Computer Science could benefit from the same approach. Why do we disagree? What does the nature of the disagreement tell us about the nature of the world?

Perhaps we don’t because we focus on the machine (for example, explaining differences as technical tradeoffs, or as a science of the innards of the machine itself). But, I think that those machines do not exist in a world in any way without the presence of humans. The computer was a human creation. It is imagined and built for humans, with human-centered goals (such as faster machines capable of solving more complex problems, relying on novel algorithms, protocols, and architectures). Our philosophy turns in significant part on a belief that what is done in the machine is justifiable because it makes advances possible but those advances are human.