मिलग्राम प्रयोग "प्रिस्क्रिप्शन टू अथॉरिटी" के प्रिज्म के माध्यम से सॉफ्टवेयर विकास

पिछले हफ्ते, मैंने अपने कोड आधार से मृत कोड हटाने के लिए एक अच्छा समय बिताया। मुझे कोड हटाना पसंद है। मेरे लिए, इतनी कम चीजें कोड में चीजों को डालने के समान आनंद लाती हैं। हां, मुझे यह बहुत पसंद है कि मैं उन इंजीनियरों से हैरान हूं जो आवेदन में अनावश्यक कोड छोड़ते हैं। लेकिन सप्ताहांत में मैंने किसी को मिलग्राम के प्रयोग "प्राधिकरण में प्रवेश" ( वे हब पर इसके बारे में भी लिखा था) के बारे में बात करते हुए सुना - और मैं मदद नहीं कर सकता, लेकिन उस व्यक्ति के बीच एक समानांतर खींचना जिसने किसी अन्य इंसान और इंजीनियर को झटका दिया ज्ञात कीड़े और खराब कोड छोड़ देता है।

यदि आप स्टैनली मिलग्राम प्रयोग से परिचित नहीं हैं, तो यह इस तथ्य में निहित है कि एक्सपेरिमेंट (अधिकार वाला व्यक्ति) शिक्षक (अध्ययन की वस्तु) को आदेश देता है कि छात्र को वर्तमान के बढ़ते निर्वहन की एक श्रृंखला में हरा दें, जो दूसरे कमरे में है। विकिपीडिया चित्रण:

ई - प्रयोगकर्ता, टी - शिक्षक, एल - शिक्षार्थी

प्रयोग का सार अपने नैतिक सिद्धांतों के साथ संघर्ष के आदेश के लिए लोगों की प्रतिक्रियाओं का अध्ययन करना था। प्रयोग से पहले, यह माना जाता था कि अधिकांश विषय प्रयोग को रोक देंगे जैसे ही उन्हें एहसास हुआ कि वे छात्र को चोट पहुँचा रहे हैं। हालांकि, प्रयोग के दौरान यह पता चला कि हड़ताली संख्या 450 वोल्ट के अधिकतम निर्वहन तक पहुंच गई।

मिलग्राम के प्रयोगों के पहले सेट में, 65 प्रतिशत प्रतिभागियों (40 में से 26 लोगों) ने 450 वोल्ट के अधिकतम संभव मूल्य का उपयोग किया, हालांकि उनके लिए ऐसा करना सुखद नहीं था; एक निश्चित समय पर, प्रत्येक प्रतिभागी ने प्रयोग को रोक दिया और संदेह किया; कुछ प्रतिभागियों ने भाग लेने के लिए भुगतान किए गए पैसे को रोकना और वापस करना चाहते थे। प्रयोग के दौरान, प्रतिभागियों ने उत्साह और तनाव की बदलती डिग्री का अनुभव किया। वे पसीने से लथपथ, थरथराते, थरथराते, अपने होंठों को सहलाते, कराहते, अपने नाखूनों को त्वचा में खोदते, कुछ हँसते-हँसते।

जब हम ऐसे परिणामों के बारे में सीखते हैं, तो हम यह मानना ​​चाहते हैं कि हम ऐसा कभी नहीं करेंगे। हम यह मानना ​​चाहते हैं कि "केवल आदेशों का पालन करना" एक मानवीय दोष है जो हमारे पास नहीं है। लेकिन मिलग्राम के प्रयोग जैसे प्रयोगों से पता चलता है कि इस तरह का विश्वास सबसे अच्छे रूप में आशावादी है, और पूरी तरह से गलत है।

और अब जब हम जानते हैं कि लोग कैसे प्राधिकरण के प्रति प्रतिक्रिया करते हैं, जब शारीरिक दर्द दांव पर होता है, तो आइए देखें कि अधिक अमूर्त चीजों जैसे निराशा और असुविधा के बारे में प्रोग्रामर कब प्राधिकरण पर प्रतिक्रिया करते हैं। चलो मिलम प्रयोग आरेख लें और इसे फिर से डिजाइन करें ताकि विकास टीम को प्रतिबिंबित किया जा सके:

यदि हम विकास टीम को देखते हैं जैसा कि चित्रण में दिखाया गया है, तो यह बहुत आश्चर्य की बात नहीं है कि हम इंजीनियर खराब कोड क्यों छोड़ते हैं और ज्ञात कीड़े छोड़ते हैं। संभवतः किसी बिंदु पर सत्ता में मौजूद व्यक्ति ने स्पष्ट कर दिया कि हमारे पास समस्याओं को ठीक करने के लिए समय नहीं है या रोडमैप की अन्य चीजों की तुलना में इन समस्याओं को प्राथमिकता नहीं दी जाती है। या यह कि डेड कोड हटाने से यूजर को वैल्यू नहीं मिलती। नतीजतन, हम कोड को छोड़ देते हैं और अगले कार्य के लिए आगे बढ़ते हैं, हालांकि यह हमारे नैतिक कम्पास और क्या अच्छा है और क्या बुरा है की अवधारणाओं के साथ संघर्ष करता है।

मिलग्राम के प्रयोग में, विषय अक्सर झिझकते थे और एक कमरे में एक व्यक्ति को एक और छुट्टी देने के खिलाफ विरोध करते थे। ऐसे मामलों में, प्रयोग करने वाले ने पूर्वनिर्धारित वाक्यांशों में से एक को जारी रखने की मांग की:

• "कृपया जारी रखें" (कृपया जारी रखें / कृपया चलें);
• "प्रयोग के लिए आवश्यक है कि आप जारी रखें";
• "यह पूरी तरह से आवश्यक है कि आप जारी रखें" (यह पूरी तरह से आवश्यक है कि आप जारी रखें);
• "आपके पास कोई और विकल्प नहीं है, आपको अवश्य जाना चाहिए"।

शब्दों के अलावा कुछ भी नहीं, प्रयोग करने वाला यह सुनिश्चित करने में सक्षम था कि उनके खिलाफ 65 प्रतिशत विषय अन्य लोगों को वर्तमान के बहुत दर्दनाक निर्वहन के साथ हरा देंगे। मुझे आश्चर्य है कि हम सॉफ्टवेयर विकास के संदर्भ में किन शब्दों का उपयोग करते हैं?

• यह वह नहीं है जो हम तय करते हैं, लेकिन उत्पाद टीम
• हमें समय सीमा को पूरा करने की जरूरत है
• विपणन टीम अगले सप्ताह एक प्रेस विज्ञप्ति जारी करने वाली है।
• हम बहुत कम टिकट बंद करते हैं
• हम इस कोड को वैसे भी फेंक देंगे
• यह एक अस्थायी समाधान है।
• अपनी टीम के प्रदर्शन में सुधार करने की जरूरत है
• यह कम संख्या में उपयोगकर्ताओं को प्रभावित करेगा।
• यह अब हमारे लिए प्राथमिकता नहीं है।
• हम इसे बाद में ठीक कर देंगे
• यही प्रबंधन चाहता है
• इतनी देर क्यों?
• इसे और तेज करने की जरूरत है।

समाधान सुझाने के लिए मैं इसके बारे में नहीं लिख रहा हूं। मेरे पास नहीं है मैं खेती करने के लिए लिखता हूं - सबसे पहले अपने आप में - सहानुभूति और समझ । जब मुझे एक ऐसा कोड दिखाई देता है, जो मेरे मन में होने वाले आघात या व्यवहार की भावना को छोड़ देता है, तो मुझे याद रखना चाहिए कि क्रियाएं हमेशा इरादों को प्रतिबिंबित नहीं करती हैं। मुझे याद रखना चाहिए कि इंजीनियर बुरा कोड छोड़ देते हैं क्योंकि वे परवाह नहीं करते हैं - वे बुरा कोड छोड़ देते हैं क्योंकि उन्हें इसे क्रम में रखने की स्वतंत्रता नहीं थी। और वे बग को छोड़ देते हैं क्योंकि वे उपयोगकर्ताओं की परवाह नहीं करते हैं, लेकिन क्योंकि उनके पास उत्पाद रोडमैप से विचलन करने का अधिकार नहीं था।