DOI: https://doi.org/10.5334/met.165
تاريخ النشر: 2025-01-01
المؤلف: Jeroen de Haas وآخرون
الموضوع الرئيسي: السيبرنتيك والتكنولوجيا في المجتمع
نظرة عامة
في هذا القسم، ينتقد المؤلفون الحجة السائدة التي تقول إن البرمجيات لا يمكن أن تتعطل، مشيرين إلى أن الفشل في القطع الرقمية يجب أن يُعزى إلى أخطاء التصميم بدلاً من مشاكل الأجهزة. تعتمد هذه الحجة على فرضيتين رئيسيتين: “التحكم الكامل” و”الاكتفاء الذاتي”. يؤكد المؤلفون أن مهندسي البرمجيات يُعتقد أنهم يمتلكون السيطرة الكاملة على سلوك البرمجيات، مع treatingها ككيان مكتفي ذاتياً. ومع ذلك، يجادلون بأن هذه الافتراضات أصبحت غير قابلة للدفاع بشكل متزايد بسبب التعقيد المتزايد للبرمجيات، مما يجعل من المستحيل على المهندسين تحديد جميع الأخطاء بشكل موثوق. بالإضافة إلى ذلك، فإن العمليات المعنية في إنشاء وتشغيل البرمجيات أصبحت الآن متوسطة بشكل كبير، مما ينطوي على عدة عوامل وأنشطة، مما يعقد مفهوم البرمجيات ككيان مكتفي ذاتياً.
يستنتج المؤلفون أن تداعيات تحليلهم تتحدى التصنيف البسيط لفشل البرمجيات كأخطاء تصميم فقط. يبرزون أن رموز البرمجيات، حتى عند عملها على آلات محلية موثوقة، يمكن أن تظهر سلوكيات متنوعة وغير صحيحة، مما يقوض الافتراضات المتعلقة بالتحكم الكامل والاكتفاء الذاتي. يعقد هذا التعقيد تحديد رموز البرمجيات المعطلة، مما يقترح أن البرمجيات قد لا تناسب بسهولة الأطر التقليدية لتحليل القطع التقنية. وبالتالي، بينما يعترف المؤلفون بحدود الحجة ضد تعطل البرمجيات، فإنهم لا يقترحون إطاراً ميتافيزيقياً بديلاً نهائياً لفهم البرمجيات، مما يترك أسئلة مفتوحة حول طبيعتها ومسؤوليات مهندسي البرمجيات.
مقدمة
تتناول مقدمة الورقة الاعتماد المتزايد للمجتمع على القطع الرقمية وأنظمة الدعم، مع تسليط الضوء على تداعيات فشلها المحتمل. بينما تصنف الأطر الفلسفية التقليدية فشل القطع، بما في ذلك الرقمية، كتعطلات، يجادل FFP (فلوريدي، فريسكو، وبريمييرو) بأن البرمجيات لا يمكن القول بأنها تتعطل بشكل صارم. ويؤكدون أن فشل البرمجيات يتحدى النظريات الفلسفية الحالية للقطع، حيث لا يمكن تحليل هذه الإخفاقات بشكل كافٍ من خلال عدسة التعطل. تشير هذه النظرة إلى أن مهندسي البرمجيات يتحملون مسؤولية كبيرة عن الإخفاقات، والتي غالباً ما تُعزى إلى أخطاء التصميم بدلاً من مشاكل الأجهزة.
ومع ذلك، ينتقد المؤلفون موقف FFP من خلال التأكيد على التعقيدات الكامنة في ممارسات هندسة البرمجيات المعاصرة. يجادلون بأن افتراض السيطرة الكاملة على إنشاء البرمجيات ووجود تعليمات مكتفية ذاتياً غير واقعي. الطبيعة المعقدة لتطوير البرمجيات، التي تنطوي على العديد من الأنشطة الوكيلة وتفتقر إلى رموز برمجية معزولة محددة، تعقد نسبة الوظائف والإخفاقات. وبالتالي، تفترض الورقة أن فهماً ميتافيزيقياً أكثر دقة للبرمجيات والقطع الرقمية ضروري، وهو ما يبتعد عن النظريات التقليدية للقطع ويعترف بالحقائق المتعددة الأوجه لهندسة البرمجيات. ستستكشف الأقسام التالية حجج FFP، والتداعيات على نظريات الوظيفة الفلسفية، وتحليلاً نقدياً لمفهوم “التنفيذ” في تطوير البرمجيات.
نقاش
في ورقتهم لعام 2015، يؤكد فلوريدي، فريسكو، وبريمييرو (FFP) أن البرمجيات لا يمكن أن تتعطل، مميزين بين البرمجيات، والبرامج، والأجهزة. يعرفون البرمجيات على أنها تسلسل من التعليمات القابلة للتنفيذ بواسطة الآلات، بينما البرامج هي تسلسلات مكتفية ذاتياً من التعليمات التي تنفذ الخوارزميات. يجادل FFP بأن رموز البرمجيات لا يمكن أن تتعطل أو تعمل بشكل خاطئ لأنها جميعها مشتقة من نفس البرنامج والخوارزمية الأساسية، مما يثبت أدائها على مستوى النوع. وبالتالي، يجب تصنيف أي إخفاقات تُعزى إلى البرمجيات كأخطاء تصميم بدلاً من تعطل، مما يضع المسؤولية عن هذه الإخفاقات بشكل مباشر على مهندسي البرمجيات.
تحليل FFP يعتمد على مفهومي “التحكم الكامل” و”الاكتفاء الذاتي” في هندسة البرمجيات. يفترضون أن مهندسي البرمجيات لديهم القدرة على إنشاء تعليمات مفصلة تحكم أداء رموز البرمجيات، مما يضمن التناسق عبر الحالات ما لم تحدث إخفاقات في الأجهزة. تتماشى هذه النظرة مع الآراء التاريخية والمعاصرة في هندسة البرمجيات، التي تؤكد على أهمية البرمجة الدقيقة للقضاء على الغموض والأخطاء. ومع ذلك، ينتقد المؤلفون هذا الافتراض، مشيرين إلى أن ممارسات هندسة البرمجيات الفعلية غالباً ما تكشف عن انفصال عن المثالية المتمثلة في التحكم الكامل، مما يعقد نسبة المسؤولية عن إخفاقات البرمجيات فقط إلى أخطاء التصميم. يدعو هذا التحليل إلى إعادة تقييم مسؤوليات مهندسي البرمجيات في ضوء التعقيدات الكامنة في تطوير البرمجيات وتنفيذها.
DOI: https://doi.org/10.5334/met.165
Publication Date: 2025-01-01
Author(s): Jeroen de Haas et al.
Primary Topic: Cybernetics and Technology in Society
Overview
In this section, the authors critique the prevailing argument that software cannot malfunction, positing that failures in digital artifacts should be attributed to design errors rather than hardware issues. This argument relies on two key presuppositions: ‘complete control’ and ‘self-containedness’. The authors assert that software engineers are believed to have total control over software behavior, treating it as a self-contained unit. However, they argue that these assumptions are increasingly untenable due to the growing complexity of software, which makes it impossible for engineers to reliably identify all faults. Additionally, the processes involved in creating and running software are now heavily mediated, involving multiple agents and activities, which complicates the notion of software as a self-contained entity.
The authors conclude that the implications of their analysis challenge the simplistic categorization of software failures as mere design errors. They highlight that software tokens, even when functioning on reliable local machines, can exhibit varied and incorrect behaviors, undermining the presuppositions of complete control and self-containedness. This complexity complicates the identification of malfunctioning software tokens, suggesting that software may not fit neatly into traditional frameworks for analyzing technical artifacts. Consequently, while the authors acknowledge the limitations of the argument against software malfunctioning, they do not propose a definitive alternative metaphysical framework for understanding software, leaving open questions about its nature and the responsibilities of software engineers.
Introduction
The introduction of the paper addresses the increasing reliance of society on digital artifacts and support systems, highlighting the implications of their potential failures. While traditional philosophical frameworks categorize failures of artifacts, including digital ones, as malfunctions, FFP (Floridi, Fresco, and Primiero) argue that software cannot strictly be said to malfunction. They contend that software failures challenge existing philosophical theories of artifacts, as these failures cannot be adequately analyzed through the lens of malfunctioning. This perspective suggests that software engineers bear significant responsibility for failures, which are often attributed to design errors rather than hardware issues.
However, the authors critique FFP’s position by emphasizing the complexities inherent in contemporary software engineering practices. They argue that the assumption of complete control over software creation and the existence of self-contained instructions are unrealistic. The intricate nature of software development, which involves numerous agential activities and lacks definitive, isolated software tokens, complicates the attribution of functions and failures. Consequently, the paper posits that a more nuanced metaphysical understanding of software and digital artifacts is necessary, one that diverges from traditional artifact theories and acknowledges the multifaceted realities of software engineering. The subsequent sections will explore FFP’s arguments, the implications for philosophical function theories, and a critical analysis of the notion of ‘implementation’ in software development.
Discussion
In their 2015 paper, Floridi, Fresco, and Primiero (FFP) assert that software cannot malfunction, distinguishing between software, programs, and hardware. They define software as an ordered sequence of machine-executable instructions, while programs are self-contained sequences of instructions that implement algorithms. FFP argue that software tokens cannot dysfunction or misfunction because they all derive from the same underlying program and algorithm, which fixes their performance at the type level. Consequently, any failures attributed to software should be classified as design errors rather than malfunctions, placing the responsibility for such failures squarely on the software engineers.
FFP’s analysis hinges on the notions of “complete control” and “self-containedness” in software engineering. They posit that software engineers have the ability to create detailed instructions that govern the performance of software tokens, ensuring uniformity across instances unless hardware failures occur. This perspective aligns with historical and contemporary views in software engineering, which emphasize the importance of precise programming to eliminate ambiguity and errors. However, the authors critique this presupposition, suggesting that actual software engineering practices often reveal a disconnect from the ideal of complete control, thereby complicating the attribution of responsibility for software failures solely to design errors. This analysis invites a reevaluation of the responsibilities of software engineers in light of the complexities inherent in software development and execution.