Jeroen de Haas

Digital artifacts often fail to perform as expected. It has recently been argued that this should not be analyzed as software malfunctioning. Rather, every case that is not the result of hardware failures would be due to design errors. This claim, which hinges on the notion of ‘implementation’, highlights a potential fundamental difference between software and other technical artifacts. It also implies that software engineers have more extensive responsibilities than creators of other artifacts. After reconstructing the argument, we show that it rests on two presuppositions regarding the nature of software and the activities of its creators, which we call ‘complete control’ and ‘self-containedness’. Software is taken to be a self-contained unit through which the software engineer exerts complete control over a machine’s behavior. These two presuppositions as well as the usage of implementation and strong claims regarding responsibility can be found throughout the literature on software engineering. Still, we argue that the presuppositions are untenable in light of current practices. For one thing, software engineers cannot exert complete control because software has become too complex for any technique to reliably locate every fault in it. For another, the creation and running of software are nowadays heavily mediated processes involving many agential activities. As a result, the performance of digital artifacts may vary, often in undesirable ways, without either hardware failures or design errors. This undermines the conclusion that software cannot malfunction, while also revealing the complications in developing a metaphysical account of software that fits contemporary practices.

Software, like technical artifacts, is discussed and evaluated in terms of its functions. According to intentionalist function theories, the function we ascribe to an object should reflect the intended effect on its environment as fixed by its designer. In this paper, I demonstrate how we develop an intentionalist understanding of the functions of software, despite recent arguments to the contrary. For this, I analyze software design and use from an action-theoretical perspective, a methodology previously used to develop the ICE theory of technical functions. I explain why the arguments raised against intentionalist function theories are no cause for abandoning them in the context of software. Next, I introduce an ICE-like alternative for understanding function ascriptions to software. This identifies what I call configured effectuation mechanisms as function bearers. Finally, I show how my intentionalist function theory enables the uniform evaluation of software by designers and users.