Is constraint a noun or an adjective in ICT4D? A talk at SAICSIT 2010
4 November 2010

Recently, I had the pleasure of attending and speaking at the 2010 Annual Research Conference of the South African Institute for Computer Scientists and Information Technologists (SAICSIT2010).   Congratulations and thanks to the hosts, the Meraka Institute of South Africa’s CSIR.  It was a great chance for me to meet more of the CS and IS research communities in South Africa, and particularly to meet lots of researchers working on ICT4D related projects.

My plenary talk covered three main themes

Many of the slides were photo-heavy and text-light, so they don’t stand alone very well.  But you can follow the links above for background on parts 1 and 2. 

As for the new ideas, I’ll share a few core elements below.  Comments and queries are quite welcome here – these ideas need discussion before they can be considered really stable.  Indeed they are already changing a bit from the original comments at SAICSIT, so don’t treat this like a transcript.

Nouns and Adjectives: Remarks on Constraint and ICT4D

Why ICT4D? Why carve out ICT4D, when we can apply traditional approaches like Computer Science, Informatics, HCI, Psychology and Economics?

The answer, I think, is that in theory and in practice, ICT4D is inherently interdisciplinary, and usually requires collaboration or synthesis in order to be successful.  I mentioned Mike Trucano’s list of “10 Worst Practices in ICT for Education” presented at Failfare (DC) as a great illustration/discussion of how many different factors can trip up would-be ICT4D interventions. I also returned to the discussion of mobile internet training we did in Khayelitsha.  The successes and failures of that training could be understood from a variety of lenses, from political economies of the South African labor market, to mobile HCI, to gender and family structures, to pricing and telecommunications service provisions.  No single discipline has a sufficiently broad analytic frame to account for the complexities of most ICT4D interventions or processes. 

After establishing this interdisciplinary tension, I suggested that in ICT4D, constraint (economic, social, human, environmental, technical) is an implicit but critical concept, inviting contributions from multiple research perspectives.  This observation was not intended as a an examination of the definitions/boundaries of “I”, “C”, “T”, “4”, or especially “D”. Instead, it simply identified a concept intentionally broad enough to facilitate interdisciplinary exchange within ICT4D. Various forms of “constraint” can be evoked as:

  • Designing for constraints (economic, infrastructural, skills)
  • Predicting behavior under constraints (pricing, policy)
  • Reducing constraints (agency, freedom, power)

The thing that is both exciting and challenging is that the various disciplines in ICT4D are unlikely to share a single specific definition of constraint. The differences may boil down to what is being constrained – the human (user) or the technology.

For many social scientists, constraints are limits on a human being’s possible actions. These constraints range from individual-level psychological factors (skills, emotions, knowledge) to micro-social local conditions, (peer groups, families), to macro-level social constructs (cultures, institutions, economies, networks). As such, constraints both reflect and reproduce complexity, and are unavoidable products of the embeddedness of humans, technologies, and social systems; multiple constraints are always present…and will always be present.  To social scientists, constraints are big, permanent fixtures in human societies – constraints are nouns, if you will, with properties of their own.

Meanwhile for many computer scientists and engineers, constraints represent the conditions under which a proposed technical solution must function.  A proposed solution X must work under constraints A, B, and C or it is not a “solution”. In this way, constraints present boundaries to technical challenges, but also make them harder.  (e.g., it is one thing to create an m-banking application – it is another thing to make with work for cheap handsets, low-literacy, and unreliable security protocols). Consider this slide, which reproduces some of the topics from the call for papers for the upcoming SIG-DEV event in London.  The bold terms [formatting is my addition] suggest a focus on technical constraints, where a number of constraints are offered as adjectives “low-cost”, “intermittent”, “low-literacy”, “disabled”, modifying other perhaps more familiar and less problematic nouns like “networks”, “connectivity” or “languages”.

image

Despite these differences, “constraint” seems to me to be a term that, at least most people within ICT4D, regardless of their research background, can discuss, explore, engage, and confront.  If there’s one thing that everyone in ICT4D can agree on, its that we’re working in a landscape full of conditions which can be described as constraints.  This baseline commonality is not necessarily the case with some other concepts in ICT4D, from justice to productivity to agency to freedom.  I haven’t actually sat down and tried to build an interdisciplinary case for the other such terms, but my hunch is that they each present more difficulties if the goal is cross-disciplinary collaboration and synthesis.

A focus on constraint as a facilitative concept brings a few things into focus for ICT4D:

1. The arrival of computer science and engineers in the conversation seems to have roughly coincided with the introduction of ICT4D as a term around 2001-2002.  Before that, terms like “the digital divide’ or “the new world information order” or “Mass communications and international development” were more central. These earlier incarnations of the interdisciplinary field we now know as ICT4D were concerned with social and economic change, in using the power of information and communications media to create a more fair, more prosperous, more healthy, more heterogeneous society in a world filled with constraints on human action).  However from the 1950s to the 1990s, it was the exception, rather than the norm, to have the active involvement of computer scientists and engineers who could actually build (or adapt) specific technologies to work under conditions of both technical and social/structural constraint.  

2. It is difficult for a single practitioner or researcher to use constraint as an adjective and a noun at simultaneously. To move between technical and social-structural lenses, between software stacks and sustainable business models, between interface design and alternative cognitive structures, or between creating user affordances and navigating political economies is challenging; to bring them all to bear on a single ICT4D project  is harder still. 

3. Each approach to constraint has a logical distillation (extreme) which can undermine an ICT4D project or analysis. When constraints are approached as nouns, used to describe barriers to human action, there is a risk of analytic and practical paralysis, in which every critique offers another critique, offers a multiplicity of overlapping and semi-permanent constraints, or brings another layer of complexity to the challenges of making things better for (or with) someone else. Conversely, when constraint s are introduced as adjectives, modifying and limiting the applicability of a technical solution,  the distillation (in isolation) may be a narrow focus on satisfying a problem defined by a small set of contextual factors constraints, and an unchallenged expectation that most problems can be solved via technologies, given the right resources and time horizon.  

There are at least two ways to confront this breadth of concepts and constraints. 

Richard Heeks proposes one approach in his article on ICT4D 2.0, suggesting that ICT4D needs “to develop or find ICT4D champions who are tribrids: They must understand enough about the three domains of computer science, IS, and development studies to draw key lessons and interact with and manage domain professionals.”(p 31).  These renaissance researchers (my word, not Heeks’) are rare but not impossible to develop.  Anyone with a combination of technical knowledge, the willingness to dive deeply into social scene and development theory, and the willingness to spend time in the field, with would-be users of various ICTs, might be able to become a renaissance researcher. 

Alas, I’ll probably never be a tribrid or a renaissance researcher. I come from a social science background.  Even though I now work at MSR in the midst of some of the best technical innovators in the domain, I can’t code my way out of a paper bag.

Which brings me to the other way we can address the interdisciplinarity of ICT4D, which is through productive collaboration.  (Heeks mentions this approach as multidisciplinary teambuilding).   It is not by chance that some of the best work in ICT4D comes out of labs or institutes where computer scientists, engineers, social scientists, and designers are encouraged to overlap. In South Africa, these places include the Meraka Institute (the host of SAICSIT2010), the UCT Centre in ICT4D, (where I get to hang out) and the Siyakhula Living Lab. Elsewhere, examples include my very own Technology for Emerging Markets Group at MSR India.  Recently I’ve been working on a project alongside a designer and three HCI specialists, and they bring such different lenses and insights to bear on our topic.  I could not be learning what I’m learning without them  (details coming soon…)

In either case, via renaissance researchers or via collaborations, these vehicles for interdisciplinary exchange and synthesis are a key to good ICT4D work. Indeed, the renaissance and the collaboration mechanisms are best ways to embrace and be informed by these different forms of constraint.   Conversation and collaboration can draw each view of constraint back away from its distillations, towards a nuanced but actionable middle ground where remarkable work can be done. 

image