श्रोडिंगर प्रोग्रामर, डेपॉप्स और कैट

एक नेटवर्क इंजीनियर की वास्तविकता (नूडल्स और ... नमक के साथ?)

हाल ही में, इंजीनियरों के साथ विभिन्न घटनाओं पर चर्चा करते हुए, मैंने एक दिलचस्प पैटर्न देखा।

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

जब आप इस विचार पर सवाल उठाते हैं और बताते हैं कि जटिल प्रणालियों में रैखिकता फिर से भ्रामक है, तो एक आकर्षक चर्चा का जन्म होता है। डिबेटर्स जोर देकर कहते हैं कि केवल "मूल कारण" का ज्ञान हमें समझने की अनुमति देता है कि क्या हो रहा है।

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

मैं हमेशा सोचता था कि ऐसा क्यों? क्या प्रोग्रामर "मूल कारण - मिथक" के विचार की आलोचना करते हैं? एक प्रतिरक्षा प्रणाली की तरह जो एक विदेशी एजेंट को पहचानता है। वे इस तरह से प्रतिक्रिया क्यों करते हैं जबकि इस विचार पर विचार करने की अधिक संभावना है?

मुझे पूरा यकीन नहीं है, लेकिन इस संबंध में एक विचार है। यह विभिन्न संदर्भों से जुड़ा हुआ है जिसमें ये पेशेवर दैनिक कार्य करते हैं।

डेवलपर्स अक्सर नियतात्मक उपकरणों के साथ काम करते हैं। बेशक, कंपाइलर, लिंकर्स, ओएस सभी जटिल प्रणालियां हैं, लेकिन हम एक नियतात्मक परिणाम देने के लिए उपयोग किए जाते हैं, और हम उन्हें निर्धारक के रूप में प्रस्तुत करते हैं: यदि हम एक ही इनपुट डेटा प्रदान करते हैं, तो हम आमतौर पर इन प्रणालियों से समान आउटपुट की उम्मीद करते हैं। । और अगर कोई समस्या है ("बग"), तो डेवलपर्स इसे इनपुट डेटा (या तो उपयोगकर्ता से या विकास प्रक्रिया में उपकरणों के एक सेट से) का विश्लेषण करके हल करते हैं। वे एक "त्रुटि" की तलाश करते हैं और फिर इनपुट को संशोधित करते हैं। यह बग को ठीक करता है।


सॉफ्टवेयर विकास की मुख्य धारणा: एक ही इनपुट डेटा मज़बूती से और निश्चित रूप से एक ही आउटपुट देता है

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

किसी भी मामले में, नियतत्ववाद एक बुनियादी है, जो लगभग उन कार्यक्रमों के लिए स्वीकृत धारणा के लिए लिया जाता है जो प्रोग्रामर करते हैं।

लेकिन किसी भी देवोपा के लिए जो दिन बिताने के लिए रैक में लोहे को इकट्ठा करता है या क्लाउड एपीआई को छांटता है, पूरी तरह से निर्धारक दुनिया का विचार (जब तक कि सभी इनपुट डेटा प्रदर्शित करने का अवसर है!), सबसे अच्छा, एक क्षणभंगुर अवधारणा है। यहां तक ​​कि धूप के धब्बों के बारे में BOHF के चुटकुले भी , अनुभवी इंजीनियरों ने इस दुनिया में सबसे अजीब चीजें देखीं। वे जानते हैं कि यहां तक कि एक मानव चीख एक सर्वर को धीमा कर सकती है , न कि लाखों अन्य पर्यावरणीय कारकों का उल्लेख करने के लिए।

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

बेशक, मैं यह नहीं कह रहा हूं कि डेवलपर्स भोले हैं, बेवकूफ हैं, या यह समझने में असमर्थ हैं कि रैखिकता कैसे धोखा दे सकती है। अनुभवी प्रोग्रामर ने भी शायद अपने जीवनकाल में बहुत अधिक गैर-नियतत्ववाद देखा।

लेकिन यह मुझे लगता है कि इन विवादों में डेवलपर्स से सामान्य प्रतिक्रिया अक्सर इस तथ्य से संबंधित होती है कि संपूर्ण रूप में नियतात्मकता की अवधारणा उन्हें रोजमर्रा के काम में अच्छी तरह से काम करती है। वे गैर-नियतत्ववाद का सामना नहीं करते हैं क्योंकि अक्सर इंजीनियरों को अपने बुनियादी ढांचे पर श्रोडिंगर बिल्लियों को पकड़ना पड़ता है।

हो सकता है कि यह डेवलपर्स की देखी गई प्रतिक्रियाओं को पूरी तरह से स्पष्ट नहीं करता है, लेकिन यह एक शक्तिशाली अनुस्मारक है कि हमारी प्रतिक्रियाएं कई कारकों का एक जटिल मिश्रण हैं।

इस जटिलता को ध्यान में रखना महत्वपूर्ण है, चाहे हम किसी एक घटना की जांच कर रहे हों या एक सॉफ्टवेयर वितरण पाइपलाइन पर एक साथ काम कर रहे हों, या एक व्यापक दुनिया की समझ बनाने की कोशिश कर रहे हों।