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’, high...
Saved in:
| Main Authors: | , |
|---|---|
| Format: | Article |
| Language: | English |
| Published: |
Ubiquity Press
2025-01-01
|
| Series: | Metaphysics |
| Subjects: | |
| Online Access: | https://account.metaphysicsjournal.com/index.php/up-j-m/article/view/165 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| _version_ | 1823859337475391488 |
|---|---|
| author | Jeroen de Haas Wybo Houkes |
| author_facet | Jeroen de Haas Wybo Houkes |
| author_sort | Jeroen de Haas |
| collection | DOAJ |
| description | 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. |
| format | Article |
| id | doaj-art-90a25fe8b5a642bcb23f10db6d16ba08 |
| institution | Kabale University |
| issn | 2515-8279 |
| language | English |
| publishDate | 2025-01-01 |
| publisher | Ubiquity Press |
| record_format | Article |
| series | Metaphysics |
| spelling | doaj-art-90a25fe8b5a642bcb23f10db6d16ba082025-02-11T05:39:39ZengUbiquity PressMetaphysics2515-82792025-01-01811–151–1510.5334/met.165165Can’t Software Malfunction?Jeroen de Haas0https://orcid.org/0000-0003-3249-2049Wybo Houkes1https://orcid.org/0000-0003-3148-4805Avans University of Applied SciencesEindhoven University of TechnologyDigital 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.https://account.metaphysicsjournal.com/index.php/up-j-m/article/view/165digital artifactssoftware failuremalfunctioningimplementationsoftware engineeringartifact functions |
| spellingShingle | Jeroen de Haas Wybo Houkes Can’t Software Malfunction? Metaphysics digital artifacts software failure malfunctioning implementation software engineering artifact functions |
| title | Can’t Software Malfunction? |
| title_full | Can’t Software Malfunction? |
| title_fullStr | Can’t Software Malfunction? |
| title_full_unstemmed | Can’t Software Malfunction? |
| title_short | Can’t Software Malfunction? |
| title_sort | can t software malfunction |
| topic | digital artifacts software failure malfunctioning implementation software engineering artifact functions |
| url | https://account.metaphysicsjournal.com/index.php/up-j-m/article/view/165 |
| work_keys_str_mv | AT jeroendehaas cantsoftwaremalfunction AT wybohoukes cantsoftwaremalfunction |