Sprinting with Data

Editor's Notes

• #4: Murder on the Orient Express Sidney Lumet, 1974 adaptation of Agatha Christie's novel, in which Albert Finney's Hercule Poirot solves the murder of a wealthy American aboard the titular train
• #6: Adaptation is delayed, because it is turned to the future. Unlike the quarrels on the existence of global warming and its link with human activities, the debate on adaptation does not concern how we have messed the climate (in the past) or what we can do to fix it (in the present). It concerns what we will do when the effects of climate change will eventually hit us. And, though we know that such effects will be massive, we don’t know exactly what they will look like. Not only because climate is an amazingly complex (in fact quasi-chaotic) system, but because its change is due to the interference of social systems whose evolutions are even more unpredictable. As scenarios replace predictions, different actors choose the futures that they like the best or fear the most. Controversies, therefore, concern not only how should we prepare for the future, but also what future should we prepare for.
• #7: Adaptation is dispersed, because it concerns the localization of the effects of global warming. Unlike the discussion on the mitigation of climate change, the debate on adaptation does not concern global tendencies but local effects. Unlike the causes of climate change (the greenhouse gases that mix and spread in the atmosphere), its effects are highly localized. Adaptation is not concerned about the transformation of the global climate system, but about such transformation will trickle down to local microclimates. And even if we are still largely incapable to down scale our models, we know that global warming will strike differently in various parts of the world, unsettling different natural and social sectors and often in opposite directions. Though it derives from an international tragedy of the commons (mitigation can only be multilateral), adaptation can only be tackled at a national or even local level.
• #8: Adaptation is diffused, because it concerns the transformation of pre-existing sectors. By definition adaptation concerns the re-organization of non-climatic systems. It is the adaption of agricultural practices, of infrastructures, of rural and urban settlements, of industrial installations. Adaptation discussions, therefore are always mixed with the pre-existing socio-technical debates. Unlike the quarrels on the existence and the mitigation of climate change, adaptation does not create a new arena, but displace existing socio-technical debates. When a rich country help a poorer one to set up a new water distribution system, is this climate adaptation, or development aid, or humanitarian intervention?
• #9: Adaptation is opportunistic, because it mobilizes an increasing amount of human and financial resources. If IPCC projections are right, the efforts to deal with climate will consume a greater proportion of our social and economic resources in the near to long term future. Social and institutional actors know this all too well and use climate adaptation as leverage to advance other interests and other interests as leverage to advance climate adaptation. They hide adaptation under other policies and other policies under adaptation. They strive to increase their present resources as much possible while reducing their future margins of action as little as possible.
• #16: The heterogeneity of the actors involved. Hackathons and barcamps are generally organized as to be open to many different types of actors. In part, this comes from the need to achieve deliverable results at the end of the event, which demands to collect all the necessary competences to go through all the phases of the project. In developing marathons, this translates in having experts from the entire programming stack: from setting up the server infrastructure, to designing the wireframes, from scraping the data to implementing the front-end. The push for heterogeneity also derives from the necessity to exchange with the potential end users of the projects, who should be at hand during the developing dash. The effort to convene participants physically. The unity of time and place that characterize hackathons and barcamps seemed an appropriate counterbalance to the dispersion of research efforts often observed in international and interdisciplinary projects. One of the problems of working across disciplines is that the experts of one field have a blurred appreciation of what experts of other fields may need as an input for their work. Such misunderstandings are normal in interdisciplinary projects and can become disastrous if discovered too late – a risk particularly salient for international projects. Yes, technologies for distant cooperative work can ease up some of these difficulties, but nothing facilitates mutual supervision and speed up collaboration more than direct presence. One more time, ‘digital’ turned out to be opposite to ‘virtual’. Exploiting digital inscriptions demands to coordinate the efforts of many different disciplines and this in turn demands to convene in the same space and time. The “quick and dirty” (or “design to cost”) approach. Though thriving on the same increase in the availability of digital inscriptions, hackathons and barcamps are somewhat opposite to ‘big data’ approaches. The short and intensive nature of these events shields them from the dream of exhaustivity often associated with ‘big data’. Participants know that they will only able to treat a limited amount of digital traces and that they will achieve imperfect results, but they accept such constraints more as a challenge than as a weakness. Making the most out of light infrastructures, simple logistics and agile organization methods, participants are well aware that their work should hack code and information gathered in earlier projects and that their outcomes should become the bases for further ventures. Not only hackathons and barcamps foster iterations within their meetings, but they are explicitly conceived as intermediary steps of a larger developing cycle.
• #17: Data sprints are always preceded by a long and intense work of preparation. When participants meet up, most of the research infrastructure should have already been collected and prepared for treatment. Time-consuming operations such as data cleansing or infrastructures setting-up should be accomplished beforehand, so that the days of the sprint can be dedicated entirely to the operations that require a more direct collaboration. Also participation to data-sprints is not open: sprinting lineup and team formation is taken care in advance, to make sure that the working groups contains all the competences needed to achieve significant results. Data-sprints are also generally longer and more structured than their antecedents. While hackathons and barcamps are usually organized on two or three days, sprints work better when they extend over a full working week. Finally, data-sprints require a greater follow-up than hackathons and barcamps. The ‘quick end dirty’ approach that characterizes the five days of a sprint should be complemented by an extensive work of refinement and documentation, in order to endow the results with the precision and robustness demanded by scientific research.
• #21: 1) Posing research questions. Research questions are posed on the first day of the sprint by the invited issue experts. Besides suggesting a number of research questions, issue experts are also invited to help the other participants (most of whom have little previous knowledge of the issue at stake) to get grips with the topic of the meeting. This can be done through Q&A sessions or panel discussions, but it also (and often more fruitfully) through informal consultations as part of the running feedback on data visualizations. 2) Operationalizing research questions into feasible digital methods projects. In a sense, this process begins already before the sprint where the organizers try to anticipate what type of projects the sprint might led to. We found that an excellent way of doing this initial vetting is to ask issue experts to suggest interesting datasets. This provides a chance to get back to the experts explaining why the proposed dataset may be unsuitable for certain research questions and thus getting them attuned to what a digital methods project can and cannot achieve. 3) Procuring and preparing datasets. As mentioned above, while it is desirable to have datasets available in advance, this is sometime at odds with the agility of the sprint and it is not uncommon that complementary data have to be search and collected in the first days of the sprint. 4) Writing and adapting code. Sprints are issue-specific (meant to address particular needs of the controversy actors) and their aim is less to develop generic tools than to adapt existing code to the research questions rose by the issue experts. This does not mean, however, that effort shouldn’t be invested in making datasets, scripts and visualizations re-usable beyond their original projects. Sprints should remain faithful to their communitarian roots and ensure that all the data, code and contents produced are liberated through of open-source, copy-left and open-publishing licenses. 5) Designing data visualizations and interface. One of the driving forces of sprints is that they deliver tangible outcomes. These outcomes may have different forms, but they always share the characteristic of being directly usable by actors of the controversy. In many cases, this translates with the issue experts leaving the sprints with tangible results that they immediately mobilize in their debates. 6) Eliciting engagement and co-production of knowledge. Data-sprints abide by the ‘co-production of knowledge model’ of social sciences advocated for by Callon, Lascoumes, & Barthe (1999). Such approach assumes that scientific activities should be pursued in a constant and genuine dialogue with their publics. If data-sprints are organized according to the five phases described above, it is distinctively for this final phase to be achieved. If sprints fail in creating a common space for social scientists and social actors, they will have failed in all other respects as well.
• #22: The issue experts/alpha users: Regardless of the subject matter of the sprint, the first order of business is always to formulate research questions. This is done with the help of people that have something at stake in the topic of the sprint (either because they are affected by it, produce knowledge about it, intervene politically in it, or a combination of the above). They are at once the issue experts, who are able to deploy their matters of concern for the rest of the participants, and the alpha users, who will be able to provide feedback and commentary on the intermediary results. The selection of these issue experts/alpha users does not presume to be representative (as is for example the case in citizen conferences) but is driven by the research collective's need to acquire stakes in the controversy. The developers: Sprints are supposed to be agile. They must be able to adapt not only to what the issue experts/alpha users bring to the table, but to what the research collective as a whole make of these contributions. The one asset that more than anything ensures this agility (or hampers it if neglected) is developers. Successful sprints are fundamentally anathema to the idea that development needs can be fully anticipated much less serviced in advance. The job of the developers is both to adapt tools and scripts for particular analysis needs, harvest missing data, and help the designers build applications for exploring the datasets. The project managers: Research questions must be asked in such a way that they are both feasible with the available digital methods and pertinent to the concerns of the issue experts. This requires a translational competence. Project managers must be sufficiently knowledgeable of the controversy to understand the questions posed by the issue experts and sufficiently adept with digital methods to see the potentials and constraints flagged by designers and developers. The project managers become, in a sense, the stewards of the alpha users, helping them to express their need and to lake sense of the results produced. The designers: Competences in information visualizations are mobilized throughout the sprint process. Visualizations are essential to facilitate the iterative exploratory data analysis (Tukey, 1977) on which the sprint is based. They are also crucial for making sure that the results of the sprint are delivered in a form that makes them largely available to controversy publics (Latour, 2005b). The sprint organizers: Besides making the necessary practical arrangements for the sprint to take place (booking rooms and accommodation, organizing food, distributing programs and practical info, etc.) the organizers play a key role in the preparatory phase leading up to the sprint. The most obvious occasion for this is the decision on the overall sprint theme. Although sprints should be agile enough to accommodate evolving research questions, thematic framing is necessary for an effective mobilization of issue experts. Such experts are likely to be dedicated people with busy agendas. It falls to the sprint organizers to provide them with an incentive by giving them a sense of what their stake in the sprint could be. Thematic framing is also necessary for pre-collecting datasets. Again, although sprints should be agile enough to accommodate the harvesting of new datasets, the organizers should do what they can to anticipate relevant datasets.