This is a part of the symposium on socially extended knowledge
Hinchey, M., Jackson, M., Cousot, P., Cook, B., Bowen, J. P., & Margaria, T. (2008). Software
engineering and formal methods. Communications of the ACM, 51(9), 54-59.
However, to balance things out- one could also notice that verbal and non-verbal communication occurring repeatedly among team members (especially in the forms of kinesics, oculesics, proxemics, or chronemics) might constitute a potential transformative factor in the equation (Ciancarini et al., 2021), which may prompt a defender of distributed cognition to consider instances of such scientific knowledge as locally (and -partially- socially) distributed. This is because, one may argue, the partnership -especially when leading to positive results- is not limited to several (non-physical) interactions at one point in time, but it unfolds in proximity and through forms of incremental (direct and indirect) contact among developers that are scaffolded over prolonged periods of time in which each individual is cognitively responsible for her cognitive success, but also becomes responsible for the cognitive success of her group.
Pritchard, D. (2022). Socially Extended Scientific Knowledge. Frontiers in Psychology, 3001, doi: –
https://www.frontiersin.org/articles/10.3389/fpsyg.2022.894738/full[1] Associate Professor and Head of Human Machine Lab, Faculty of Humanities and Social Sciences, Innopolis University, Innopolis, 420500, Republic of Tatarstan, Russian Federation
Software teams may succeed or fail for reasons that go beyond the technology in use, the skills, or the internal dynamics of the specific project being implemented by certain team members; and the reasons for such failures could be sought in external factors, including organizational, psychological, and sociological ones. In fact, one may venture to say that such (external) factors very often play a crucially important (instrumental or constitutive) role in the practice of software development and software engineering more in general. Yet, most of the research conducted on software development to date has been focusing uniquely on formalized procedures and techniques (Hinchey et al., 2008) derived from logic and mathematics to control any change in the software writing process, [often] forgetting about the importance of individuals in their relations and collaborative partnerships with the environment. A few computer scientists though (e.g., Fagerholm et al., 2022) recently argued that psychological and sociological factors may actively influence and directly shape the process that leads to the production of software programs, thereby emphasizing that the creation of a software is -more often than not- a process that requires ‘distributed intelligence’ across team members (Capretz, 2014; Feldt et al., 2010).
Capretz, L. F. (2014). Bringing the human factor to software engineering. IEEE software, 31(2), 104.
Regardless of which of these two interpretations might be correct (perhaps it is a matter – as often the case- that can be resolved empirically, by testing out large amounts of developers), it seems fairly evident that such cases point to a significant [and perhaps] increasing role of embodiment in scientific discussions, thereby reaffirming the need and necessity of ever more research on such topics, and -hence- confirming the validity of the intuition underlying our special issue.
References
Indeed, writing software often requires several programmers working collaboratively and interactively (within increasing amount of complexity) with the same code base (e.g. Git). Software configuration management systems responsible for managing changes in software programs (including VCS) typically offer ‘feature branches’ to help software engineers isolating their changes and subsequently integrating them into the source code trunk. However, when a development team is very large and the intensity of the changes is significant, software engineers often face the so-called problem of stale branches (branches of any given repository that have become too large and haven’t -because of that- been dealt with by anyone in a very long time). This situation is undesirable for IT companies because it slows down the production line, often preventing or delaying the realization of a project. To prevent such situations from happening IT companies force programmers to leave TODO markers in any unresolved branch. These puzzles are then converted to new tasks when the branch gets merged into the trunk. Such tasks are then reassigned to developers for completion, typically [but not exclusively] by the project manager (Farina et al., 2022). This process of assigning tasks through supervision streamlines the workflow and typically boosts both productivity and efficiency.
[2] The distinction between synchronic and diachronic actions is often taken in the literature as a measure to discriminate between extended and distributed cognition.
Farina, M., Karimov, A., Zhdanov, P., Lavazza, A. (2022). AI and Society: a Virtue Ethics
Approach. AI & Society, doi: https://doi.org/10.1007/s00146-022-01545-5
This is because one may perceive the process of writing a software as unfolding synchronically rather than evolving diachronically; so, -in brief- as being scaffolded at specific points in time rather than conceiving it as an evolutionary/developmental procedure[2]. One may also maintain that in each step of the software writing process the contribution of the individual involved can still be clearly tracked and therefore easily singled out (for instance, by tracking the developers’ interactions via TODO markers), meaning that such contribution does not ‘holistically disappear’ in the new form of knowledge that is being created. On these grounds, one may well interpret such a procedure -in agreement with Pritchard – as a case study for extended individual cognition, whereby each individual partaking in the practice is ‘cognitively responsible for her cognitive success’.
Fagerholm, F., Felderer, M., Fucci, D., Unterkalmsteiner, M., Marculescu, B., Martini, M., … &
Khattak, J. (2022). Cognition in Software Engineering: A Taxonomy and Survey of a Half-
Century of Research. ACM Computing Surveys, 54 (11), pp.1-36. Doi:
https://doi.org/10.1145/3508359
Commentary on ‘Socially Extended Scientific Knowledge’
Feldt, R., Angelis, L., Torkar, R., & Samuelsson, M. (2010). Links between the personalities, views
and attitudes of software engineers. Information and Software Technology, 52(6), 611-624.
Ciancarini, P., Farina, M., Masyagin, S., Succi, G., Yermolayeva, S., Zagvoskina, N. (2021). Non
Verbal Communication in Software Engineering — an Empirical Study. IEEE Access, 9, 71942 –
71953doi: 10.1109/ACCESS.2021.3075983
by Mirko Farina[1]
Pritchard’s Socially Extended Scientific Knowledge is part of a special issue titled: ‘Distributed and Embodied Cognition in Scientific Contexts’. The goal of the special issue is to investigate and critically evaluate the relevance and significance of the paradigm of distributed cognition in a variety of scientific contexts (ranging from cognitive ecologies and material culture to embodied cognition and human-computer interaction). Pritchard’s paper represents a valuable contribution to the special issue because it provides our readers with a helpful three-tiered ‘philosophical cartography’ (or a ‘philosophical hygienics’, as the authors say) that is aimed at charting out the conceptual space surrounding social knowledge, with specific reference to that knowledge ‘found in collaborative scientific enterprises’. Pritchard, in particular, argues that we should be cautious (and therefore refrain from) attributing distributed knowledge to teams, because: ‘while we can coherently talk of a group of researchers having knowledge, there are [still] natural ways of understanding this claim in terms of the knowledge of the individuals within the group’.
In this brief commentary, I discuss a practice in software engineering that represents an illustration of Pritchard’s three-tiered taxonomy and argue – in agreement with Pritchard- that such a practice is (probably) best described by the extended cognition research program rather than by its distributive counterpart. Nevertheless, I also point out some constraints to this idea, that should be carefully considered and evaluated in future research.
It is beyond the scope of this short commentary to discuss the nitty-gritty details of the practice of writing a software; however, such a practice (as described above) can be used to illustrate the point made by Pritchard in his paper. During the production of a particular software program each of the developers involved in the process may be said to possess forms of extended knowledge that are required and demanded to meaningfully participate in collaborative, incremental actions with other actors in the team; however, it does not follow that the team as a result will acquire ‘distributed knowledge’; and hence, it is still quite possible to assert that the relevant knowledge [while being extended] still ‘belongs to the individuals within the group’.