Can’t Software Malfunction?

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.