Synthese

, Volume 192, Issue 4, pp 1199–1220 | Cite as

On malfunctioning software

Article
First Online:
Received:
Accepted:

Abstract

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.

Keywords

Artefact Design Dysfunction Function Misfunction Software 
This is a preview of subscription content, log in to check access

Notes

Acknowledgments

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.

References

  1. Angius, N. (2013). Abstraction and Idealization in the formal verification of software systems. Minds and Machines, 23(2), 211–226.CrossRefGoogle Scholar
  2. 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.
  3. Berry, M. D. (2011). The philosophy of software: Code and mediation in the digital age. New York: Palgrave Macmillan.CrossRefGoogle Scholar
  4. Colburn, T. (1998). Information modelling aspects of software development. Minds and Machines, 8(3), 375–393.CrossRefGoogle Scholar
  5. Colburn, T. (1999). Software, abstraction and ontology. The Monist, 82(1), 3–19.CrossRefGoogle Scholar
  6. Colburn, T., & Shute, G. (2007). Abstraction in computer science. Minds and Machines, 17(2), 169–184.CrossRefGoogle Scholar
  7. Davies, P. S. (2000a). Malfunctions. Biology and Philosophy, 15(1), 19–38.CrossRefGoogle Scholar
  8. Davies, P. S. (2000b). The nature of natural norms: Why selected functions are systemic capacity functions. Noûs, 34(1), 85–107.CrossRefGoogle Scholar
  9. Fetzer, J. (1999). The role of models in computer science. The Monist, 82, 20–36.CrossRefGoogle Scholar
  10. Floridi, L. (2011). The philosophy of information. Oxford: Oxford University Press.Google Scholar
  11. Franssen, M. (2006). The normativity of artefacts. Studies in History and Philosophy of Science, 37, 42–57.CrossRefGoogle Scholar
  12. Fresco, N., & Primiero, G. (2013). Miscomputation. Philosophy and Technology, 26, 253–272. doi: 10.1007/s13347-013-0112-0.
  13. Gotterbarn, D. (1998). The uniqueness of software errors and their impact on global policy. Science and Engineering Ethics, 4(3), 351–356.CrossRefGoogle Scholar
  14. Gruner, S. (2011). Problems for a philosophy of Software Engineering. Minds and Machines, 21(2), 275–299.CrossRefGoogle Scholar
  15. Hansson, S. O. (2006). Defining technical function. Studies in History and Philosophy of Science, 37(1), 19–22.CrossRefGoogle Scholar
  16. 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
  17. Hodges, W. (1995). The meaning of specifications I: Initial models. Theoretical Computer Science, 152, 67–89.CrossRefGoogle Scholar
  18. Houkes, W., & Vermaas, P. E. (2010). Technical functions: On the use and design of artefacts. Dordrecht: Springer.CrossRefGoogle Scholar
  19. Hughes, J. (2009). An artifact is to use: An introduction to instrumental functions. Synthese, 168(1), 179–199.Google Scholar
  20. Irmak, N. (2012). Software is an abstract artifact. Grazer Philosophische Studien, 86(1), 55–72.Google Scholar
  21. Jespersen, B., & Carrara, M. (2011). Two conceptions of technical malfunction. Theoria, 77(2), 117–138.CrossRefGoogle Scholar
  22. Kirchner, H., & Mosses, P. (2001). Algebraic specifications, higher-order types and set-theoretic models. Journal of Logic and Computation, 11, 453–481.CrossRefGoogle Scholar
  23. Millikan, R. G. (1989). In defense of proper functions. Philosophy of Science, 56(2), 288–302.CrossRefGoogle Scholar
  24. Neander, K. (1995). Misrepresenting & malfunctioning. Philosophical Studies, 79(2), 109–141.CrossRefGoogle Scholar
  25. 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.
  26. Northover, M., Kourie, D. G., Boake, A., Gruner, S., & Northover, A. (2008). Towards a philosophy of software development: 40 Years after the birth of software engineering. Journal for General Philosophy of Science, 39(1), 85–113.CrossRefGoogle Scholar
  27. 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
  28. 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
  29. 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.
  30. Suber, P. (1988). What is software. Journal of Speculative Philosophy, 2(2), 89–119.Google Scholar
  31. Symons, J. (2008). Computational models of emergent properties. Minds and Machines, 18(4), 475–491.CrossRefGoogle Scholar
  32. Symons, J., & Boschetti, F. (2013). How computational models predict the behavior of complex systems. Foundations of Science, 18(4), 809–821.CrossRefGoogle Scholar
  33. Turner, R. (2005). The foundations of specification. Journal of Logic and Computation, 15, 623–662.CrossRefGoogle Scholar
  34. Turner, R. (2011). Specification. Minds and Machines, 21(2), 135–152.CrossRefGoogle Scholar
  35. 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
  36. Winsberg, E. (1999). Sanctioning models: The epistemology of simulation. Science in Context, 12(2), 275–292.CrossRefGoogle Scholar
  37. Wright, L. (1973). Functions. Philosophical Review, 82(2), 139–168.CrossRefGoogle Scholar

Copyright information

© Springer Science+Business Media Dordrecht 2014

Authors and Affiliations

  • Luciano Floridi
    • 1
  • Nir Fresco
    • 2
  • Giuseppe Primiero
    • 3
  1. 1.Oxford Internet InstituteUniversity of OxfordOxfordUK
  2. 2.Sidney M. Edelstein CentreThe Hebrew University of JerusalemJerusalemIsrael
  3. 3.Department of Computer ScienceMiddlesex UniversityLondonUK

Personalised recommendations