Conference Agenda

Overview and details of the sessions of this conference. Please select a date or location to show only sessions at that day or location. Please select a single session for detailed view (with abstracts and downloads if available).

 
 
Session Overview
Session
(Papers) Malfunction
Time:
Wednesday, 25/June/2025:
5:00pm - 6:30pm

Session Chair: Samuela Marchiori
Location: Auditorium 3


Show help for 'Increase or decrease the abstract text size'
Presentations

That’s not a bug, that’s an accidental function: on malfunctioning artifacts and concepts

Herman Veluwenkamp1, Sebastian Köhler2

1University of Groningen, The Netherlands; 2Frankfurt School of Finance & Management, Germany

Our current frameworks for understanding malfunction and function fail to capture the diverse ways in which objects, both physical and abstract, can fail to do what they are for. In this paper, we address that limitation by proposing a new account of “functioning” and “malfunctioning.” We do this by focusing not only on technical artifacts, but also on two different kinds of entities that can be defective: software and concepts.

Let us start with software. Although it seems intuitive that software, like other human-made objects, should be subject to the same kind of malfunction analysis (Franssen 2006), Floridi, Fresco, and Primiero (2015) have argued that software tokens cannot malfunction. In their view, a software “failure” either reflects a universal design flaw or a hardware issue. If the same erroneous instructions are present in all copies of a given program, there is no token-level failing; at most, software misfunctions by producing unintended side effects.

However, this appears to conflict with everyday experiences of software that “breaks” in specific, idiosyncratic ways. For example, consider a word processor that randomly freezes on some computers. This might be caused by font packages, which are only installed in some offices, that trigger the crashes. This is consistent with other offices having the program run smoothly for years. These kinds of local breakdowns can create unique malfunctions, which are unaccounted for in a purely type-level analysis (de Haas & Houkes 2025). It is therefore important to consider the local context, which includes custom settings, and additional software dependencies, when analysing malfunctions.

A parallel issue arises in conceptual engineering. Concepts, like software, are often described as abstract entities. Nevertheless, theorists maintain that certain concepts can fail to fulfil their function. This is taken to be a pro tanto justification for conceptual revision (see, e.g., Thomasson 2020). Moreover, it is widely acknowledged that concepts can fail for certain contexts, but are well-functioning in others. For example, our current concept of truth is taken to be defective for scientific contexts, but fine in others (Scharp 2013). However, if we define malfunction based on the relative effectiveness of a conceptual “token” compared to other tokens of its type, the possibility of local conceptual errors disappears. This obscures the different ways in which concepts can fail across different contexts.

To address these issues, we propose an account of "malfunction" and "function" that is sensitive to the diverse ways in which technical artifacts, digital artifacts, and concepts can fail. First, we define "functioning" in line with recent proposals in conceptual engineering (<removed for review>) and artifact design (<removed for review>) as the ability to produce effects that are normatively significant. Second, we define "malfunctioning" as the failure to produce these effects. We analyze the various ways in which tokens of different entities can break down and demonstrate how these instances can be subsumed under our understanding of malfunction. Finally, we show how this analysis aligns well with the responsibilities that engineers and designers have for repair, maintenance and redesign.

References

Floridi, L., Fresco, N., & Primiero, G. (2015). “On malfunctioning software.” Synthese, 192: 1199–1220.

Franssen, M. (2006). “The normativity of artefacts.” Studies in History and Philosophy of Science Part A, 37: 42–57.

de Haas, J. & Houkes, W. (2025). Can’t Software Malfunction? Metaphysics.

Scharp, K. (2013). Replacing truth. OUP Oxford.

Thomasson, A. L. (2020). “A Pragmatic Method for Normative Conceptual Work.” In A. Burgess, H. Cappelen, & D. Plunkett (Eds.), Conceptual Engineering and Conceptual Ethics (pp. 435–458). Oxford University Press.



The Ethics and Epistemology of Malfunction in Human-Technology Integration

Alexandra Karakas

Budapest University of Technology and Economics, Hungary

The development of brain implants has brought transformative potential to medical science, offering groundbreaking treatments for neurological disorders and cognitive enhancement. However, the phenomenon of malfunctioning brain implants presents not only possibilities, but besides the engineering and ethical challenges also significant epistemic opportunities. The talk explores the phenomenon I call value clash— the conflict between engineering, scientific, and ethical priorities and values—arising from malfunctions, with a particular focus on how these events illuminate the blurry boundaries between normal and malfunctioning performance. I argue that a malfunction framework is a useful epistemic tool, and is essential for advancing the science and governance of certain medical instruments.

From an engineering standpoint, malfunctions are typically framed as deviations from the intended function, prompting efforts to improve reliability and safety. Yet, defining normal artefact performances in complex cases like brain-machine interfaces is inherently challenging. The relation between technological artefacts and biological systems they interact with creates philosophical dilemmas and ambiguous zones where a certain performance could be functional yet suboptimal for the patient. Malfunctions thus calls for a re-evaluation of these boundaries, revealing ethical grey zones.

Epistemically, malfunctions are invaluable since they expose hidden assumptions about how artefacts are expected to perform. For instance, a device may work as intended but produce unwanted side effects due to unpredictable neural responses, which highlights the contingent and context-dependent nature of functionality. These cases also shed light on broader issues, such as the intricate relation between user expectations, artefact performances, and the socio-technical systems that frame their use.

Ethically, malfunctioning artefacts like brain implants underscore critical issues like accountability, communication of risks, and patient autonomy. However, these cases also reflect deeper epistemic challenges, as the uncertainty inherent in defining "normal" versus "malfunctioning" complicates ethical decision-making in sensitive cases in the medical sciences.



Ascribing functions to software

Jeroen de Haas1,2

1Avans University of Applied Sciences; 2Eindhoven University of Technology

The present work analyzes function ascriptions to software from an action theoretical perspective. Software is a key component of many (intimate) technologies, but how it contributes to their causal efficacy has not been satisfactorily explicated. Common presuppositions about its role are untenable, but nevertheless prevalent in both textbooks and literature, giving a false sense of control to current and future engineers (De Haas and Houkes 2025). This paper develops an alternative account, more closely aligned with the design and use of software.

Ordinary discourse typically treats software products as functional equivalents to technical artifacts, bespoke material artifacts created for a purpose. For instance, the sentence “I’ll set my alarm to wake me up before breakfast” might just as well concern a physical alarm clock on the speaker’s bedside table, as it might a particular app on the speaker’s smartphone. Ascriptions of functions to a function bearers have a normative quality. They assert how physical manipulation of a function bearer should contribute to the attainment of a goal state, and thereby establish a criterion for evaluating its actual causal role. An alarm clock that is ascribed the function to produce pronounced audible signals, but remains silent at the set time, is deemed to malfunction. Functional kind terms, such as ‘clock’, ‘calendar’, and ‘store’, are profitably applied to new software products to indicate they partake of the same functionality as their material counterparts. Yet, a prima facie compatibility of terms does not entail the compatibility of their referents.

Several authors have remarked upon the similarities between technical artifacts and software (Irmak 2012; Floridi, Fresco, and Primiero 2015; Turner 2018), in particular, their having a dual nature. Like technical artifacts (Kroes and Meijers 2006), software is intentionally created as a means to realize physical goal states. This is considered sufficient reason to identify software as function bearers. However, while speaking of material objects’ causal roles is unproblematic, it is unclear if, and how, functions can be ascribed to software as it is construed on their accounts. Material artifacts stand in a direct relation to their environment, where they can be manipulated, and exert their causal influence. ‘Software,’ by contrast, is used to denote a variety of entities from abstract artifacts (Irmak 2012), to physical realizations of machine-executable instructions (Floridi, Fresco, and Primiero 2015) or symbolic entities (Turner 2018). By these accounts, software is not amenable to manipulation, causally efficacious, or both. Still, it seems incontrovertible that software enables the exerting of similar causal influences on the world (e.g, introducing pronounced stimuli) despite the lack of bespoke artifacts that once were exclusively associated with their exertion (alarm clocks).

This paper demonstrates why software as construed by these authors cannot fulfill the role of function bearer in function ascriptions as they are understood for technical artifacts (c.f. Houkes and Vermaas 2010). Moreover, it identifies an alternative class of objects that suit the role of function bearer. Thus, it contributes to a better understanding of what it means to ascribe a function to software.

De Haas, Jeroen, and Wybo Houkes. 2025. “Can’t Software Malfunction?” Metaphysics 9 (1): 1–15. https://doi.org/10.5334/met.165.

Floridi, Luciano, Nir Fresco, and Giuseppe Primiero. 2015. “On Malfunctioning Software.” Synthese 192 (4): 1199–1220. https://doi.org/10.1007/s11229-014-0610-3.

Houkes, Wybo, and P. E. Vermaas. 2010. Technical Functions: On the Use and Design of Artefacts. Philosophy of Engineering and Technology. Dordrecht: Springer Netherlands. https://doi.org/10.1007/978-90-481-3900-2.

Irmak, Nurbay. 2012. “Software Is an Abstract Artifact.” Grazer Philosophische Studien 86 (1): 55–72. https://doi.org/10.1163/9789401209182_005.

Kroes, Peter, and Anthonie Meijers. 2006. “The Dual Nature of Technical Artefacts.” Studies in History and Philosophy of Science Part A 37 (1): 1–4. https://doi.org/10.1016/j.shpsa.2005.12.001.

Turner, Raymond. 2018. Computational Artifacts: Towards a Philosophy of Computer Science. Berlin, Heidelberg: Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-662-55565-1.



 
Contact and Legal Notice · Contact Address:
Privacy Statement · Conference: SPT 2025
Conference Software: ConfTool Pro 2.6.154
© 2001–2025 by Dr. H. Weinreich, Hamburg, Germany