Artefacts do not always do what they are supposed to, due to a variety of reasons, including manufacturing problems, poor maintenance, and normal wear-and-tear. Since software is an artefact, it should be subject to malfunctioning in the same sense in which other artefacts can malfunction. Yet, whether software is on a par with other artefacts when it comes to malfunctioning crucially depends on the abstraction used in the analysis. We distinguish between “negative” and “positive” notions of malfunction. A negative malfunction, or dysfunction, occurs when an artefact token either does not (sometimes) or cannot (ever) do what it is supposed to. A positive malfunction, or misfunction, occurs when an artefact token may do what is supposed to but, at least occasionally, it also yields some unintended and undesirable effects. We argue that software, understood as type, may misfunction in some limited sense, but cannot dysfunction. Accordingly, one should distinguish software from other technical artefacts, in view of their design that makes dysfunction impossible for the former, while possible for the latter.
KeywordsArtefact Design Dysfunction Function Misfunction Software
This article was developed initially as a collaboration between Jesse Hughes (see especially Hughes (2009)) and Luciano Floridi. We are extremely grateful to Jesse for having allowed us to re-use his very valuable work. We would also like to acknowledge the constructive feedback of the anonymous referees, whose comments enabled us to improve the article significantly.
- Angius, N. (2014). The problem of justification of empirical hypotheses in software testing. Philosophy and Technology, 27, 423–439. doi: 10.1007/s13347-014-0159-6.
- Floridi, L. (2011). The philosophy of information. Oxford: Oxford University Press.Google Scholar
- Fresco, N., & Primiero, G. (2013). Miscomputation. Philosophy and Technology, 26, 253–272. doi: 10.1007/s13347-013-0112-0.
- Hodges, W. (1993). The meaning of specifications II: Set-theoretic specification, Semantics of Programming Languages and Model Theory, ed. Droste and Gurevich, Gordon and Breach, Yverdon, 1993, 43–68.Google Scholar
- Hughes, J. (2009). An artifact is to use: An introduction to instrumental functions. Synthese, 168(1), 179–199.Google Scholar
- Irmak, N. (2012). Software is an abstract artifact. Grazer Philosophische Studien, 86(1), 55–72.Google Scholar
- Neander, K. (2004). Teleological theories of mental content. In E. N. Zalta (Ed.), The Stanford encyclopedia of philosophy (2012 Ed.). http://plato.stanford.edu/archives/spr2012/entries/content-teleological.
- Preston, B. (2000). The functions of things: A philosophical perspective on material culture. In P. G. Brown (Ed.), Matter, materiality and modern culture (pp. 22–49). London: Routledge.Google Scholar
- Radder, H. (2009). Why technologies are inherently normative. In A. Meijers (Ed.), Philosophy of technology and engineering sciences. Handbook of the philosophy of science (Vol. 9, pp. 887–921). Amsterdam: North-Holland.Google Scholar
- Schiaffonati, V., & Verdicchio, M. (2014). Computing and experiments: A methodological view on the debate on the scientific nature of computing. Philosophy and Technology. doi: 10.1007/s13347-013-0126-7.
- Suber, P. (1988). What is software. Journal of Speculative Philosophy, 2(2), 89–119.Google Scholar
- Vincenti, W. G. (1990). What engineers know and how they know it : Analytical studies from aeronautical history. In Johns Hopkins studies in the history of technology. New Series No. 11. Baltimore, MD: Johns Hopkins University Press.Google Scholar