CS Principles

I really like these principles. I know that they’re focused on Advanced Placement Computer Science (this is the American notion of allowing some students to take college level courses in high school). But I think they have broader relevance, (and the content behind each of these principles could distinguish what they are used to teach). What I like is that they are organized around principles that cross-cut a set of disciplinary silos Computer Science has gotten too used too. They say nothing about HCI, Systems, (a little about) Networking, perse, but require skills in all these areas. Perhaps this is just where I work, but we seem to siloed, and to mired in discussions about what fields matter the most to Computer Science. I think these present a constructive way of moving forward, by placing an emphasis on why any of these areas matter, and blending theory with practice.

Computing is a creative human activity that engenders innovation and promotes exploration.

Of course, I’m going to like this, but I think it does a nice job of putting the human in the loop of systems production, while simultaneously also suggesting that it’s not just about building things for profit or to solve business problems. Innovation is an exploration of the new… that sounds a lot more exciting than going to work for a code shop. And it also reflects an interesting reality for Software Engineering. The hard work in Software Engineering is building the solution the first time, once built (as long as it’s not changed) it’s a matter of copying it. All the work is in the first effort, and believe me it’s a lot of problem solving exploration. I know I used to work with people who did this for a living.

Abstraction reduces information and detail to focus on concepts relevant to understanding and solving problems.

This seems to me to be a fundamental skill with computing. I think it can be read in different ways. Here are two. I read here the skills that are required during modular decomposition, to get the right solution parts from the problem statement. I also read another about turning piles of interview data, through the process of analysis, into a set of outcomes, perhaps implications for design. But, it’s always the same type of challenge, a winnowing of the data through established analytic principles and mechanisms to get to a focus on the core.

Data and information facilitate the creation of knowledge.

I think there’s a relationship between abstraction and data, abstraction is the process by which you manage the data here. Perhaps even part of the process of turning it into knowledge. But there are other ways to manage data and to generate knowledge that turn on other innovations. One that springs to my mind is data visualization. I think that’s a socio-computational system where people and machines work together to create meaning from data. This also connects Computer Science with Information Science in a really nice way. I think it’s still not quite clear, from a disciplinary stance, where the boundary of Computer Science and Information Science are here. Interestingly for Georgia Tech, it also connects Computer Science to Computational Science and Engineering.

Algorithms are tools for developing and expressing solutions to computational problems.

Recently we had a talk in which someone declared that the three most important areas of computing were algorithms, algorithms, and algorithms. Some of us think (hope) he was joking, especially when he added that people were just algorithms. But, needless to say, he’s not completely wrong, algorithms are central to a discipline of machine manipulation, since they are the mechanism of machine control. Nuff said.

Programming is a creative process that produces computational artifacts.

I’m all for creativity in programming. Frankly I think that Software Engineering has come lately to creativity, agile program seems to make room from creativity. But, earlier forms of software process management tended to over-emphasize control. I think that this was largely the product of two circumstances. First, the “software crisis” has long plagued the field. The software crisis is the difficulty of predicting how long, how expensive, and so forth any software project will be. Software Engineering has been in pursuit of better predictive methods to handle the software crisis. Second, Software Engineering was initially work done within the military context, the early big systems were military ones. And Military environments have a command and control form of management, so it was not totally surprising that that was the management style applied to software engineering. So, I think creativity is important. Now, a colleague of mine, has pointed out that programming can also lead to creative user experiences, which could be missed in the use of the word artifact, but the descriptions of what could be learnt seems to include that more. Perhaps add “and experience” onto the end of the sentence.

Digital devices, systems, and the networks that interconnect them enable and foster computational approaches to solving problems.

Networks are socio-computational systems. The technical network has given rise to applications that have enabled communication and coordination. Social media is perhaps the most recent and powerful example. That’s clear in the description. I suppose if I had a nit it would be that the human side doesn’t come out quite as strongly in the principle. I’m not sure that Facebook solves a problem perse, I think it allows us to be human to connect and communicate. And that doesn’t seem problem centered to me, it’s not business communication or whatever, rather it seems to be an essential human trait. Again I owe this to the same colleague, thanks Matthew. Perhaps I would have said, Digital devices, systems, and the networks that interconnect them enable and foster computational approaches to solving problems and support human experience. I notice that I’m just adding the word experience everywhere.

Computing enables innovation in other fields including science, social science, humanities, arts, medicine, engineering, and business.

So one possibility with what’s missing above, is addressed here. This is the area of socio-computational systems. Interestingly this principle is a hybrid. The principle focuses on fields, and that could be read as on the state of the knowledge. But in the text it’s also clear it’s on the state of the practice. Teasing the two apart could be useful. Computing is a platform for advances in other fields, my colleagues in Computational Science and Engineering are working on some of these advances for other fields of Science and Medicine. But, that’s different from changing the state of the practice, from changing business practice, from changing how we live, work and play. Computing is doing both. Although I hesitate to use the word change. I sometimes think that it’s more the case that it enables new ways to do what we always did. For example, web banking allows me to do banking from a far greater range of places and at times that physical banking would be impossible. But, I’m still using it to do banking. The institution of banking, of having checking (current) and savings accounts, of making transfers, of payments, and so forth is still pretty much the banking system I grew up with. Oddly enough I think Facebook might be more of a change agent. I would like to have kept up with people from my high school, but I couldn’t possibly do that with letters or even emails frankly. The heartbeat, the pulse of life that I get through the status updates I send and that I read, does allow me to learn a little bit about what the huge number of people I’ve interacted with over the years are doing today.

Michael Mahoney: Historian of Software Engineering

I’ve come across Michael Mahoney before, but recently I read his piece on the history of the science of Software Engineering

There was a lot more going on in the article than I want to discuss here, but I wanted to bring out a few quotes.

“There is nothing natural about software or any science of software. Programs exist only because we write them, we write them only because we have built computers on which to run them, and the problems we write ultimately reflect the structures of those computers. Computers are artifacts, programs are artifacts, and models of the world created by programs are artifacts. Hence, any science about any of these must be a science of a world of our own making rather than a world presented to us by nature.”

I have often felt that we have done our best to eradicate the human from Computer Science. I like the way that Mahoney layers the humanity into the production of systems.

When I got started in HCI, not that it was called that at Irvine, instead it went by the handy title of CORPS (Computing, ORganizations, Policy and Society — the acronym had the additional advantage that people who wanted to donate their body for medical science would send us email about it too).

OK, back to the point, when I got started in HCI, I felt that the production of systems was given far less attention than the use of the systems. If human use was so key to understanding success, then why wasn’t human production as valued. I thought then, as I think now, that the humanness of producing complex machinery is one reason why it’s not actually as easy to reduce practice to theory.

There’s that quote that “in theory, theory and practice are the same. In practice they are not.” I think humans make the difference. Computers are not machines, they are human built ones, and then as Mahoney says so well these machines run programs that are yet more human built artefacts, to create human built models of a human world. Layers of humanness.

I was interested in the human nature of machine production, software and systems, for many years. I still am. I think that acceptance of this, and a rich detailed understanding of it must complement the work that we do to understand the machine centred aspects of Computer Science.

Mahoney later asks, “who created the science of software, when, where, why and how?” I agree with him that this is a critically important question. Unlocking the legacy of why and for what reasons seems especially valuable as Computer Science continues its rapid expansion and what I think is also its devolution into more distinct parts.

He suggests that a fruitful way to look at science is through it’s practice (yay). He suggests the concept of an agenda, which he describes as “what its practitioners agree ought to be done, a conensus concerning the problems of the field, their order of importance, the means for solving them, and what constitutes a solution” and argues that the agenda also provides “standing in the field by solving the problems with high priority, and especially by doing so in a way that extends or reshapes the agenda, or by posing profound problems”. While, yes, this is obvious in some ways, I still find it interesting to consider. Additionally, perhaps we should also question the processes by which the community go about setting problems. Grand Challenges is one metaphor used in Computer Science, but I have had discussions with colleagues who suggest that that might be overly engineering in focus. And whether I agree or not, I’m open to the idea that the processes by which our agenda is framed are as important as the content, for they too are human-built.

I put this quote on my facebook page “it is curious that to this day, the community distinguishes between computer science and theoretical computer science, as if the former involves some kind of science other than theoretical science. It is not clear what that other kind of science might be nor what is scientific about it.” I got suggestions that that science might be biologically inspired… in the case of protein folding. What I failed, in the course of putting the quote on my page, to do was to describe Mahoney’s position that software as science may also be science as software. In other words software may not only be a science that is being developed, but also a component of other sciences (as I understood it).

I was glad that he and I agree that the importance of an agenda are the resources allocated to it. Of course, but I have pointed out that I think that’s one challenge for HCI4D, particularly w.r.t to the National Science Foundation. I think the goals of the two communities interact in more complicated ways because they did not co-evolve together. So it’s not just how much, it’s how long and how well the resources are aligned to the agenda.

I liked his recommendation of using text books to trace the emergence and development of a discipline. He makes a wonderful argument that they contain the starting points from which the research frontier will be discovered through learning. I love that idea. Text books as codification of what is known, what is discovered, what is done, and a place from which the what is undone is suggested.

Finally, well not for him, but for this post, he suggests that no-one has done a critical documented history of the evolution of the science of Computer Science established itself in universities. Given the numerous paths its taken, as part of mathematics, engineering, and science or in contrast freestanding as is true of my alma mater, Irvine, and my current employer Georgia Tech) As Computer Science and now Information. I agree. The history of the establishment of these departments is overdue. I hope that a historian will take him up.

Computer Science, or Engineering, or something else, and HCI’s Grand Challenges

Continuing my odyssey into the world of What is Computer Science, I have been reading more papers and watching people’s posts about CHI reviews. I’ve been glad to have the time to think about Computer Science as an academic discipline, because its thinking about it in that way that scholars suggest is the central way to understand what makes our theories and concepts make sense. In other words, without thinking about Computing as an academic discipline it’s not clear why we theorize or have certain concepts. I agree. I think it must also be the context that frames what we think are the central problems of the discipline, which frames action around solving them.

Some of what I have been reading lately focuses on the engineering-science debate within Computer Science. In other words, is Computer Science a Science or an Engineering discipline. Surely this debate must lend itself to grand challenges, what our grand challenges are might look different depending on whether we view Computing as a Science or an Engineering.

But, I think that there’s another piece of Computer Science that potentially gets lost (it might be somewhat present in the Engineering argument, but I am not sure whether it is a first class citizen in the Engineering argument). Consider the ACM’s position on why Computer Science has gained legitimacy as a discipline. The Association for Computer Machinery (ACM) one of the leading professional (academic, research, practice) societies for Computer Science suggests that “Partly as a result of entry of computing technology into the cultural and economic mainstream, the battle for legitimacy has largely been won.” (ACM, Computing Curricula 2001, p10).

The ACM then suggest that our discipline, and its success is tied to the economic and cultural mainstream. Perhaps this is the Engineering view being expressed, for while I can see some aspects of Science being tied to the economic mainstream, such as Chemistry and the Pharmaceutical industry, it does not (to me) pervade all of Science.

But, whether or not we are an engineering or a science, I find the ACM’s commentary interesting. If our disciplinary legitimacy is the successful embedding of Computing into the cultural and economic mainstream then surely our context must in part be driven by successful embedding of that machine into society. And perhaps that also depends on understanding and using theories about and of society (organizations, individuals, groups, culture and society) to inform what we do, or risk separating ourselves from our sources of legitimacy. So, I might suggest that Computer Science has to reconcile a three-way context, Science, Engineering and Social Science. It seems our context must stem from all three.

That’s one set of thoughts and while I am aware that they might all hang together yet, I have another set of thoughts that are related. I view this blog as a place to think out loud, so this is me thinking.

Closer to home, I’ve been thinking about what the HCI community thinks are its grand challenges.

One that seems to be getting a lot of attention right now is Health. As I have heard it articulated, the challenges around Health are what can we do with technology to mitigate the rising costs of, and increasing demand for (through aging) health care. Admittedly I have a stake in this question, (I’m interested in something we call Wellness Informatics). But, I also find it interesting that this articulation (which is the one I’ve heard the most often) is solving a commercial/marketplace context. I also wonder whether this perspective locks us into a set of arrangements, its engineering to fix the current set of problems. Is that the right approach? Would a science perspective ask us whether our methods can inform the design of healthcare systems that reconfigure healthcare? What would we learn about our methods through their application to problems within healthcare. I wonder whether user-interaction and system-safety are potential areas to consider.

A grand challenge that I always think of in terms of Science is associated with ICT4D. If HCI engages in ICT4D I think its methods have to change. HCI’s methods illustrate the marriage of the sciences and the social sciences well. They have to be informed by both simultaneously, methods for user-centered systems have to support the design of ICTs as well as the design of usable and useful ones. And, I think that ICT4D shows HCI how their methods contain all sorts of social and cultural assumptions. So, one reason to do HCI4D is to understand how our methods are culturally sensitive (or not), so that we can have a more nuanced understanding of those very methods.

In both of these, I think the social sciences play a significant role. So significant that I think they should be given a place of consideration alongside the engineering and sciences in the construction of our grand challenges. I think HCI needs some grand challenges, and I think that they should reflect the disciplinary hybrid that Computer Science is, an engineering, a science, and a social science. Considering challenges from all angles might make them richer and stronger. (I think the same is true of much of Computer Science).

Three Paradigms of Research in Computer Science

Recently I wrote about some of the challenges that the new discipline of ICT4D faces (based on my reading of other’s scholarly discussions), and what the discussion of those challenges tells us about Computer Science. I suggested that new fields provide an opportunity to look under the disciplinary hood of Computer Science, because disciplinary challenges are usually reflections of previously hidden assumptions.

But there’s another way to example the assumptions of a discipline which is to read papers that discuss them openly. I recently read Ammon H. Eden’s “Three Paradigms of Computer Science” which does just that. He suggests that Computer Science is “unusual” in that it has three mutually exclusive paradigms that guide research in the discipline. The paradigms reflect three questions that in my own experience are asked about Computer Science. Is it a branch of Mathematics, Engineering or the Sciences? Currently he suggests that all three paradigms are at work in the methods and results being produced under the banner of Computer Science. So what are the three models?

Before turning to each of the paradigms note that for Eden, activity in Computer Science is organised around the program (including databases, WWW applications, OS, device drivers, viruses etc…) and as it is written and as it is run. So compares the paradigms based on how they treat the program methodologically, ontologically and epistemologically.

Rationalist Paradigm: Computer Science as a Branch of Mathematics (uses Theoretical CS as example)

As a branch of mathematics, writing programs is treated as a mathematical activity, and “deductive reasoning is the only accepted method of investigating problems.” p144. Programs are mathematical expressions. Research results, i.e., knowledge, focuses on program understanding their completeness (full and formal specification) and emphasizes a priori reasoning.

Technocratic Paradigm: Computer Science as a Branch of Engineering (uses Software Engineering as example)

The technocratic paradigm, Eden argues evolved in the face of arguments that the complexity of systems put the rationalist paradigm out of reach for classes of programs. Eden draws on the DeMillo, Lipton, Perlis (1979) as early evidence of this paradigm. As a branch of engineering, methods emphasize the production of reliable programs. The discipline draws on established engineering methods as well as demonstrating through rigourous testing that programs exhibit reliable behaviours. It’s impractical (or impossible?) to formally specify a program, so we turn to a posteriori knowledge (i.e., results from experience). And in this paradigm, he argues that the ontology is one of nominalism, programs do not exist in the abstract but only in the concrete. But he’s also quick to point out that there’s actually no clear theoretical commitment to the concept of a program by within this paradigm.

Scientific Paradigm: Computer Science as a Natural/Emprical Science (uses Artificial Intelligence as example)

This paradigm draws from Newell and Simon (1976). But, it’s an orientation to Computer Science as an empirical and experimental science. And it includes the experimental science of human-built entities, since programs are made by people. Eden argues that this paradigm differs from the Technocratic paradigm because the focus is not on reliability, but on scientific experimentation that is hypothesis driven, and includes also the use of programs as a tool in a hypothesis driven examination of phenomena that exist in the human or natural world. Methodologically, the scientific paradigm relies on deduction and empirical validation to explain, model and predict program behaviour. The difficulty, in practice, of always being able to deduce program properties means that the paradigm relies on both a priori and a posteriori knowledge. And the ontological assumptions made are that programs in execution are similar to mental processes.

Beki’s take away. I’ve been hearing discussions about whether Computer Science is math, engineering or science for a long time now. This helps understand that the discipline is actually all three. But, now I wonder whether it can survive as all three. Perhaps these are the cleaving points for a future for Computer Science? I also wonder whether my colleagues would subscribe to these paradigms, I’m guessing not all of them do. But I can’t help feeling that within all of this, and perhaps not entirely characterised by this piece, are some important things to understand about Computer Science. It’s definitely got me thinking, and a paper that does that is worth its weight in gold.

Newell and Simon’s Turing Award Speech from 1976.

“Computer Science is an empirical discipline. We would have called it an experimental science, but like astronomy, economics, and geology, some of its unique forms of observation and experience do not fit a narrow stereotype of the experimental method. Never the less they are experiments. Each new machine that is build is an experiment. ACtually constructing the machine poses a question to nature and we listen carefully for the answer by observing the machine in operation and analysing it by all analytical and measurement means possible.”

and

“We build computers and programs for many reasons. We build them to serve society and as tools for carrying out the economic tasks of society. But as basic scientists we build machines and programs as a way of discovering new phenomena and analyzing phenomena we already know about. Society often becomes confused about this, believing that computers and programs are to be constructed only for the economic use that can be made of them (or as intermediate items in a development sequence leading to use use). It needs to understand that the phenomena surrounding computers are deep and obscure, requiring much experimentation to assess their nature. It needs to understand that, as in any science, the gains that accrue from such experimentation and understand pay off in the permanent acquisition of new techniques; and that it is these techniques that will create the instruments to help society in achieving its goals.”

Reflections on ICT4D

This is a series of reflections about a new area of research that’s rapidly gaining traction within Computer Science. It has various names (a sign of its youth), but many call it ICT4D. A quick web surf finds the following class websites. At CMU you can take Human Computer Interaction in the Developing World, at Washington and Berkeley you can take classes for Computing or Information and Communications Technologies for the Developing World. At Stanford you can take a class on Technologies for Liberation, which is part of a broader program on Liberation Technology, which takes a different perspective but clearly has relationship to the focus on emerging nations where many of these problems are particularly acute. And here at Georgia Tech we offer multiple classes in this space, including Computing4Good and Computers, Communications and International Development.

Classes are not just a necessity but also a reflection of topics that faculty think are important or interesting to teach. So, from this, and other evidence such as the growth in HCI4D work at the ACM CHI conference, and the NDSR workshop held at SOSP and previously at SIGCOMM conferences.

I’m interested in ICT4D, well something a bit different to that, for two reasons.

First, I supervise students who have contributions to make to the emerging body of scholarship in this area. One student, Susan Wyche, has used multi-sited ethnography to understand how ICTs are used in Kenya, Brazil and the United States. Another student, Andrea Grimes, is interested in ICTs for underserved communities within the U.S. Both do work that pushes on the definition of ICT4D. Traditionally, by virtue of being in the U.S., Andrea’s work would not be part of ICT4D. And yet, questions of design, implementation, and evaluation in under resourced communities cuts across her work in ways that are not dissimilar to discussions within ICT4D. What makes this all the more interesting is that Susan’s work which from it’s multi-sited nature is very central to ICT4D also pushes on definitions, by showing how somewhat resourced communities already appropriate ICTs, thus pushing on the idea that ICT4D is not what we will do but also what is already happening.

Second, I’m interested in ICT4D because it affords an opportunity to look at the discipline of Computer Science. I’m very interested in the formation of disciplines, how Science is a human-organized process, and how its organization affects what we do. ICT4D is going through some struggles with identity and legitimacy, and the questions that it raises give us a rare opportunity to examine the assumptions implicit in the discipline that it is trying to find its home within.

Here are some of what I have learnt so far, which drawn from the CCC‘s Global Development meeting (and of course my own reading of the materials)

Some participants, i.e. those who come from CS orientations, struggle to answer the question “where’s the Computer Science in ICT4D?” And others list numerous opportunities (to empirically show what the potential might be for areas that span the fields of Computer Science, such as low-cost connectivity, getting content into developing regions via novel networking architectures and caching systems, mobile and low-OS footprint applications, power management, computer vision for detection problems in health).

But others have observed that the question is also an opportunity to inspect the assumptions that underlie the production of knowledge within Computer Science. Some people observe the following. First, that CS has been focused on problems that are experienced by those solving them. Second, that in publication, and the review that leads to that, Computer Scientists prioritize the solution to the problem, rather than the problem itself. And these are related. Clearly, if you pick problems you have first hand experience with then the balance time spent on problem discovery versus solution would likely emphasize the solution. ICT4D problems are not those that many (but not all) in Computer Science have spent time experiencing, so problem discovery and exploration take considerably more time. Some observe that HCI has done a good job of making problem explication a part of the science, but also note the difficulty that HCI continues to have in establishing its legitimacy in Computer Science.

Another argument that I’ve seen is that Computer Science tends to prioritize the complex technological solution over the simpler technological solution. One manifestation of this is to value high-end over low-end. This made me reflect on various research programs within Computer Science, including the relatively new “many-core” area. Many-core, like peta-scale and high-performance computing, emphasize in their very titles the high-endness of the technology platforms that are at once both problem and solution. I’ve wondered whether when many-core is not enough, whether we’ll move to an almost Seussian “many-more many-core” agenda.

And my point here is that it seems quite “natural” within Computer Science to organize an agenda around an abundance of complex technologies. ICT4D may have an abundance of cellphones, particularly low-end cellphones, but even that’s not always the case. The absence of complex technology makes the agenda harder to express. This is compounded by the fact that many other areas of Computer Science organize around machine components, databases, compilers, even networking, computer architecture, programming languages. Areas like Software Engineering and HCI are different, perhaps that also contributes to the difficulty that they sometimes have in being treated as legitimate areas of activity. Like Software Engineering and HCI, ICT4D as people note is not organized around abundance, it’s organized around a domain, and even that domain is contested and complicated.

ICD4D is truly interdisciplinary. It involves bringing people from multiple disciplines together. And the argument is made that the range of disciplines is bigger than HCI (also posited as an interdisciplinary field of Computer Science). But, I think it’s more than just in research process that interdisciplinary teams are needed, but also in the ways that solution success are measured. The objective of ICT4D is to solve hard research problems that simultaneously make a difference in the lives of people underserved by ICTs. We don’t measure CS by the good that it’s created for the middle class of America, we measure it by the complexity of the solution.

Actually, we do also measure the impact on the middle (and upper classes) of America, impact being the favoured keyword, when we talk about the innovations that Computer Science has provided and the ubiquity of those solutions in society (through, of course, largely corporate channels). So, our measures have been economic success for corporate America. But, does that seem like the right measure for ICT4D? Particularly since the business in a position to take advantage of ICT4D innovations is likely in the United States or another industrialized nation. But, even when we draw on this impact, people still conduct research on how we measure the impact of technologies.

ICT4D causes me, at least, to reflect on economic impact (which favors those who create successful start-ups since they are likely the only people who can easily draw a line between what they’ve done and how many people have purchased it or use it) as a metric for Computer Science’s impact. Additionally, given the difficulties of finding appropriate measures, I can’t help wondering whether ICT4D is being asked to put the cart before the horse, if we’re learning how to measure productivity gains for computer use in corporate America (who have had computers in place for decades) is it perhaps unrealistic to have well-understood metrics for settings where getting the computer in is going to be a significant first challenge?

Measuring the impact of the solution seems to be further compounded by the goals of the people who sometimes fund ICT4D research: NGO’s, philanthropic agencies, and so forth. Their goals and research goals can be hard to line up. This is not uncommon in research, all funding agencies have goals for the work that they support. But, the interaction between the traditional funding agencies for Computer Science and the emphasis on complex solutions, seems to be a better match, than the match between complex solutions with little problem discovery, and the goals of NGOs to understand long-term sustained improvement. The latter, at least I think, emphasizes solving the right problem, the one that can have the most impact, and given the lack of experience with the domain, that in turn means that the problem discovery phase is inherently going to be longer than the time that the measures of good Computer Science research support. There’s an interaction between the way that the science is rewarded and the way that the funding agencies reward it, and I think the gulf is wider in ICT4D because the science and the funding agencies didn’t evolve together.

In other words having a real-world, timely-measurable, good impact on a group of people for whom their problems and the relevance of technologies for solutions are open and ill-defined questions at the beginning of study, raises significant challenges and ones that seem at odds with the ways that Computer Science does disciplinary business. Further, it’s not clear that this situation improves when ICT4D is funded from traditional funding agencies.

Another assumption that comes to light when reading within the ICT4D literature concerns the place of abstraction in Computer Science. A solution that is generalisable, i.e. abstract enough that it works in all cases, is highly valued. In this way, Computer Science is perhaps no different from other sciences that seek fundamental principles. But, ICT4D is either a considerable distance from having those general solutions, or perhaps as some think is not a field of abstractions but of instances and understanding how instances differ as part of understanding what impact on people’s very different cultural, social, economic, geographical, political lives might be.

Finally, two other challenges for ICT4D. What impact means also turns on sustainability of the solution, it has to be something that works. Works in place, after the research team leave, by the people for whom it was designed. In traditional CS, if we do give our results to end-users (although frequently we let the marketplace do that for us) it is supported by a reliable power infrastructure, an educational infrastructure that gives many the knowledge to operate and manipulate the system, and so forth. So much less exists, and therefore so much more is required in ICT4D and by ICT4D practitioners. Also, these infrastructural absences appear to challenge our processes. HCI has many accounts of how participatory design failed because the people working with the researchers didnt understand why they didn’t know the answers, or that software was mallable enough to be the subject of redesign, or what the relationship between a paper prototype and the final system might be. Are we ready to have our methods turned over because actually they weren’t general enough? I think we should risk it, because what ICT4D will do is to expose the assumptions we make about access, wealth, market systems, education, power, etc… will all come to the forefront clearly.

So, I’d like to thank ICT4D for giving me an opportunity to look under the hood of Computer Science. As the area continues to grow, so these questions will be answered in some way, how is the open question right now.

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.