في الأسبوع الماضي ، قضيت وقتًا لا بأس به في إزالة الكود الميت من قاعدة الكود لدينا. أحب حذف الكود. بالنسبة لي ، هناك القليل من الأشياء التي تجلب نفس المتعة في ترتيب الأشياء في الكود. نعم ، أحبها كثيرًا لدرجة أنني أشعر بالحيرة من المهندسين الذين يتركون رمزًا غير ضروري في التطبيق. لكن في عطلة نهاية الأسبوع سمعت شخصًا يتحدث عن تجربة ميلغرام "الخضوع للسلطة" ( كتبوا أيضًا عن ذلك على المحور) - ولم أتمكن من المساعدة سوى رسم موازٍ بين الشخص الذي صدم إنسانًا آخر والمهندس الذي يترك الأخطاء المعروفة والرمز السيئ.
إذا لم تكن على دراية بتجربة Stanley Milgram ، فستكون في الحقيقة أن المجرب (شخص يتمتع بالسلطة) يأمر المعلم (موضوع الدراسة) بالتغلب على الطالب في سلسلة من التصريفات المتزايدة للتيار ، وهو في غرفة أخرى. التوضيح ويكيبيديا:
ه - مجرب، مدرس تي، لام متعلم
كان جوهر التجربة هو دراسة ردود أفعال الناس على الأوامر التي تتعارض مع مبادئهم الأخلاقية. قبل التجربة ، كان يعتقد أن معظم المواد ستوقف التجربة بمجرد أن تدرك أنها تضر الطلاب. ومع ذلك ، خلال التجربة ، تبين أن عددًا لافتًا من الموضوعات وصل إلى الحد الأقصى لإفراز 450 فولت.
في المجموعة الأولى من تجارب Milgram ، استخدم 65 في المائة من المشاركين (26 من أصل 40 شخصًا) القيمة القصوى المحتملة البالغة 450 فولتًا ، على الرغم من أنه لم يكن من الجيد أن يفعلوا ذلك ؛ في مرحلة معينة من الزمن ، توقف كل مشارك عن التجربة وشكك فيها ؛ أراد بعض المشاركين التوقف وإعادة الأموال التي دفعوها للمشاركة. خلال التجربة ، واجه المشاركون درجات متفاوتة من الإثارة والإجهاد. تعرقوا ، ارتعدوا ، تعثروا ، شفت شفاههم ، انينوا ، وحفروا أظافرهم في الجلد ، ضحك بعضهم بعصبية.
عندما نتعلم عن هذه النتائج ، نريد أن نصدق أننا لن نفعل ذلك أبدًا. نريد أن نصدق أن "مجرد طاعة الأوامر" هي عيب بشري ليس لدينا. لكن تجارب مثل تجربة ميلجرام تظهر أن هذا الإيمان متفائل في أحسن الأحوال ، وخاطئ تمامًا في أسوأ الأحوال.
والآن بعد أن عرفنا كيف يتفاعل الناس مع السلطة ، عندما يكون الألم الجسدي على المحك ، دعونا نرى كيف يتفاعل المبرمجون مع السلطة عندما يتعلق الأمر بأشياء أكثر تجريدية ، مثل الإحباط والإزعاج. لنأخذ مخطط تجربة ميلهام وأعد تصميمه ليعكس فريق التطوير:
إذا نظرنا إلى فريق التطوير كما هو موضح في الرسم التوضيحي ، فليس من المفاجئ أن نترك مهندسينًا سيئين ويتركون أخطاء معروفة. ربما أوضح الشخص الذي في السلطة في وقت ما أنه ليس لدينا وقت لإصلاح المشكلات أو أن هذه المشكلات ليست لها أولوية مقارنة بأشياء أخرى في خريطة الطريق. أو أن إزالة الكود الميت لا يجلب قيمة للمستخدم. نتيجة لذلك ، نترك الكود كما هو وننتقل إلى المهمة التالية ، على الرغم من أن هذا يتعارض مع بوصلة أخلاقية ومفاهيم ما هو جيد وما هو سيء.
في تجربة ميلغرام ، غالبًا ما ترددت الموضوعات واحتجت على إرسال تفريغ آخر لشخص في غرفة أخرى. في مثل هذه الحالات ، طالب المجرب بمواصلة واحدة من العبارات المحددة مسبقًا:
- "الرجاء المتابعة" (يرجى المتابعة / يرجى المتابعة) ؛
- "التجربة تتطلب أن تستمر" ؛
- "من الضروري للغاية أن تستمر" (من الضروري للغاية أن تستمر) ؛
- "ليس لديك خيار آخر ، يجب أن تستمر".
باستخدام لا شيء سوى الكلمات ، تمكن المجرب من التأكد من أن 65 بالمائة من الأشخاص ضد إرادتهم يتغلبون على أشخاص آخرين بإفرازات مؤلمة جدًا من التيار. أتساءل ما هي الكلمات التي نستخدمها في سياق تطوير البرمجيات؟
- هذا ليس ما نقرره ، ولكن فريق المنتج
- نحن بحاجة إلى الوفاء بالموعد النهائي
- فريق التسويق على وشك إصدار بيان صحفي الأسبوع المقبل.
- نغلق عدد قليل جدًا من التذاكر
- سنرمي هذا الرمز على أي حال
- هذا هو الحل المؤقت.
- تحتاج إلى تحسين أداء فريقك
- سيؤثر هذا على عدد صغير من المستخدمين.
- هذه ليست أولوية بالنسبة لنا الآن.
- سوف نصلحها لاحقًا
- هذا هو ما تريد الإدارة
- لماذا وقت طويل؟
- تحتاج إلى القيام بذلك بشكل أسرع.
أنا لا أكتب عن هذا من أجل اقتراح حل. ليس لدي. أكتب لكي أزرع - أولاً وقبل كل شيء بنفسي - التعاطف والتفاهم . عندما أرى رمزًا يترك شعورًا بالحيرة أو السلوك الذي لا أفهمه ، يجب أن أتذكر أن الإجراءات لا تعكس دائمًا النوايا. يجب أن أتذكر أن المهندسين يتركون كودًا سيئًا ليس لأنهم لا يهتمون - إنهم يتركون كودًا سيئًا لأنهم لم يتمتعوا بحرية ترتيبه. وهم يتركون الأخطاء ليس لأنهم لا يهتمون بالمستخدمين ، ولكن لأنهم لا يتمتعون بالسلطة اللازمة للانحراف عن خريطة طريق المنتج.