ICSE 2018 ट्रिप रिपोर्ट: 50 साल की सॉफ्टवेयर इंजीनियरिंग

अधिकांश सामान्य कुर्सियाँ और सभी 40 आईसीएसई बैठकों की कार्यक्रम कुर्सियाँ।

सॉफ्टवेयर इंजीनियरिंग अनुसंधान का क्षेत्र इस वर्ष 50 साल पुराना है; सबसे बड़ा, सबसे पुराना, और सबसे अच्छा सॉफ्टवेयर इंजीनियरिंग सम्मेलन, सॉफ्टवेयर इंजीनियरिंग पर अंतर्राष्ट्रीय सम्मेलन, 40 साल पुराना है। इस वर्ष का सम्मेलन समुदाय के लिए पिछली आधी सदी के शोध पर फिर से देखने और पूछने के लिए एक शानदार मौका था, “हमने क्या सीखा है? हम क्या भूल गए हैं? हम क्या याद कर रहे हैं? ”मैंने इस सवाल का जवाब देते हुए, गोटेबोर्ग, स्वीडन में सप्ताह बिताया, जो इन व्यावहारिक सवालों और जवाबों पर चिंतन करता है, लेकिन इन सवालों के जवाब देने के बारे में मेरे अपने विचार साझा किए हैं।

अपने पहले पूरे दिन को किक करने के लिए, मैंने माइनिंग सॉफ्टवेयर रिपोजिटरीज़ में ओपनिंग कीनोट दिया।

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

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

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

गोथेनबर्ग के विश्व संस्कृति संग्रहालय में MSR भोज।

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

अब्राम वृद्धिशील वैज्ञानिक प्रगति की आवश्यकता के बारे में बात कर रहे हैं।

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

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

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

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

एरिक्सन रिसर्च के अध्यक्ष मैग्नस फ्रोडे ने बुधवार को वायरलेस संचार और 5 जी पर एक मुख्य भाषण दिया। उन्होंने हमारे डिजिटल अनुभवों में तेजी से बदलाव की भविष्यवाणी की शुरुआत की, लेकिन नेटवर्किंग के बुनियादी ढांचे में बदलाव की धीमी गति भी। उन्होंने तर्क दिया कि 5G मानक की स्थिरता IoT में सभी प्रकार के नए परिवर्तनकारी बुनियादी ढांचे के लिए होगी, जिसमें रीयल-टाइम मशीन-टू-मशीन संचार भी शामिल है। वह 5 जी इंफ्रास्ट्रक्चर के ब्योरे में गहरी डुबकी लगाता है, जो मुझे सॉफ्टवेयर इंजीनियरिंग के लिए सूखा और ज्यादातर अप्रासंगिक लगता है, लेकिन बात के अंदर दबी हुई सम्मोहक दृष्टि लोगों और मशीनों के बीच संपर्क का अकल्पनीय पैमाना था जो अनिवार्य रूप से विलंबता को समाप्त करता है। मैग्नस ने तर्क दिया कि यह नए अनुभवों को नाटकीय रूप से आसान बना देगा क्योंकि सिस्टम को हार्डवेयर तैनाती के बजाय कम-विलंबता नेटवर्क वाली सेवाओं के माध्यम से पूरी तरह से बनाया जा सकता है।

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

क्रिस परिन शिक्षण जटिलता की जटिल चर्चा करते हुए।

मैंने सॉफ़्टवेयर इंजीनियरिंग शिक्षा और प्रशिक्षण ट्रैक पर सत्र के बाकी बुधवार को भाग लिया (जो कि मैं 2020 में सह-अध्यक्षता करूंगा, लेकिन मुझे भी लगता है कि यह काफी महत्वपूर्ण है, और कंप्यूटिंग शिक्षा में मेरी रुचि के लिए केंद्रीय है)। यह ट्रैक सॉफ्टवेयर इंजीनियरिंग के बारे में कठोर, सहकर्मी की समीक्षा कंप्यूटिंग शिक्षा अनुसंधान प्रकाशित करता है। सॉफ्टवेयर इंजीनियरिंग सिखाने के लिए एक बड़े जटिल सॉफ्टवेयर कार्यान्वयन iTrust का उपयोग करने के बारे में बात करने के साथ क्रिस Parnin ने पहले सत्र को बंद कर दिया। उन्होंने पाया कि छात्रों ने पाठ्यक्रम के बाद एक बड़ी जटिल प्रणाली के साथ गहन जुड़ाव की सराहना की, लेकिन उन्होंने पाठ्यक्रम के दौरान इसका आनंद नहीं उठाया। विरासत कोड के साथ काम करना भारी था। उन्होंने परियोजना के साथ कक्षा की गतिविधियों को संरेखित करके पाठ्यक्रम को संशोधित किया, जिससे पाठ्यक्रम के बारे में बहुत अधिक सकारात्मक भावनाएं पैदा हुईं (जैसा कि उम्मीद की जानी चाहिए, छात्रों को अपनी सगाई को बनाए रखने के लिए कक्षा गतिविधियों के आसपास एक सुसंगत कथा की आवश्यकता है)। एक अन्य चर्चा में पाया गया कि सक्रिय वीडियो देखना, जिसमें शिक्षार्थी सामग्री पर टिप्पणी करते हैं और टिप्पणियों की समीक्षा करते हुए वीडियो देखने में व्यस्तता बढ़ जाती है। कुछ वार्ता प्रयोगशालाओं, कैपस्टोन और अन्य अनुभवात्मक अधिगम परियोजनाओं पर केंद्रित थी। आम तौर पर इन अध्ययनों में पाया गया कि अनुभवात्मक शिक्षण वास्तव में तार्किक रूप से निष्पादित करने के लिए कठिन है, प्रामाणिक बनाने के लिए चुनौतीपूर्ण है, और यह जानना बहुत कठिन है कि मूल्यांकन कैसे किया जाए। लगता है जैसे हमें इस काम को व्यवस्थित करने के लिए अनुभवात्मक सीखने के कुछ सिद्धांतों की आवश्यकता है।

रीड होम्स ने छात्रों की सीखने की चीज़ों पर चर्चा की।

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

ब्रह्माण्ड का वर्षा वन सचमुच नम था!

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

गुरुवार सुबह मैंने ब्रेंडन मर्फी, लॉरी विलियम्स और यूडब्ल्यू पीएचडी के साथ नाश्ता किया। हमारे होटल के नाश्ते के कमरे में छात्र केल्विन लोन्कारिक। हमारे मन में प्रिय दो भव्य चुनौतियों के बारे में विस्तृत चर्चा हुई: मानव और सामाजिक प्रणालियों के साथ प्रोग्रामिंग भाषाओं जैसी औपचारिक प्रणालियों का सामंजस्य करना, और मानव और सामाजिक प्रणालियों के साथ मशीन सीखने जैसी सांख्यिकीय प्रणालियों को समेटना। मेरे विचार में, ये कंप्यूटर विज्ञान की दो सबसे महत्वपूर्ण चुनौतियाँ हैं, और फिर भी कंप्यूटर विज्ञान के अधिकांश लोग इनकी अनदेखी कर रहे हैं। ब्रेंडन के पास वास्तविक परियोजनाओं के साथ डेटा विश्लेषण और मशीन सीखने को एकजुट करने की जटिलताओं के बारे में बहुत कुछ था, लॉरी ने सॉफ्टवेयर विकास में सुरक्षा के लिए लेखांकन के साथ समान चुनौतियों के बारे में बहुत सारी बातें कीं, और केल्विन ने इन समस्याओं को डेटा संरचना संश्लेषण के अपने काम में माना। जहां संश्लेषित कोड की समझ और उसकी विनिर्देश भाषा की उपयोगिता पर विचार खुले प्रश्न हैं।

इतिहास की व्याख्या करते हुए फ्रेड ब्रूक्स जूनियर।

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

मार्गरेट हैमिल्टन प्रोग्रामिंग मेनफ्रेम की कहानियों को साझा करते हुए।

दूसरे गुरुवार सुबह मुख्य वक्ता मार्गरेट हैमिल्टन थे, जिन्होंने "सॉफ्टवेयर इंजीनियरिंग" वाक्यांश की कल्पना की थी। वह एक गणित की छात्रा थीं, जब उन्होंने LGP30 पर MIT विकासशील मौसम सॉफ्टवेयर में इंटर्न करने का फैसला किया, और सॉफ्टवेयर में रुचि विकसित की, और उन्होंने अंततः अपोलो का निर्माण किया। सॉफ्टवेयर सिस्टम जो संयुक्त राज्य अमेरिका को चंद्रमा पर उतरने की अनुमति देता है। उसकी बात, "एक सॉफ्टवेयर इंजीनियर के रूप में भाषा," बड़ी समस्याओं के बारे में बात की: एकीकरण, evolvability कठिन है, पुन: उपयोग कठिन है, और सॉफ्टवेयर विफल रहता है। उसने पूछा, हमने 50 साल में इतनी कम प्रगति क्यों की है? उसने तर्क दिया कि कुछ हो गया है। पहले कोई मैदान नहीं था; अब वहाँ है। हम परिभाषित शब्द हैं। लेकिन वास्तविकता यह है कि सॉफ्टवेयर इंजीनियरिंग एक विशिष्ट मानव, विशिष्ट सामाजिक, और विशिष्ट बौद्धिक कार्य है, और हम अभी भी इनमें से अधिकांश कारकों से जूझ नहीं पाए हैं। उसने लोगों, सॉफ्टवेयर, त्रुटियों और त्रुटि सुधार के बीच इंटरैक्टिव सिस्टम बनाने की बुनियादी एचसीआई चुनौतियों का उदाहरण दिया, और ये कैसे चंद्रमा पर उतरने के लिए केंद्रीय थे। उसने महसूस किया कि सिस्टम प्रकृति में अतुल्यकालिक, वितरित और घटना-संचालित हैं, और सॉफ्टवेयर लिखने के लिए उपयोग की जाने वाली भाषाओं को यह प्रतिबिंबित करना चाहिए। उसने इसे पुन: प्रयोज्य, विश्वसनीय पैटर्न के माध्यम से वास्तुकला के माध्यम से नियोजन की आवश्यकता की चर्चा के साथ संतुलित किया। मुझे Q & A में इतिहास की समुदाय की मान्यता, इसके मूल्य और क्षेत्र के कुछ सबसे बड़े विचारों के दूर के मूल को देखकर गर्व हुआ।

UCLA के मिरयुंग किम डेटा साइंस भूमिकाओं के एक आकर्षक अध्ययन के बारे में बात कर रहे हैं।

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

गुरुवार को आखिरी सत्र 50 साल के सॉफ्टवेयर इंजीनियरिंग का उत्सव था। ब्रायन रैंडेल ने 1968 में पहले सॉफ्टवेयर इंजीनियरिंग पर एक पूर्वव्यापी दिया था। ब्रायन ने अभी तक कंप्यूटिंग के बारे में कितना कम आविष्कार किया था, इस बारे में बात की थी; कोई इंटरनेट नहीं, कोई नेटवर्क नहीं, कोई पुन: उपयोग नहीं। और फिर भी सभी मुद्दे थे: परीक्षण, शुद्धता, प्रबंधन, आदि। ब्रायन को प्रोग्रामिंग और सॉफ्टवेयर इंजीनियरिंग के बीच प्रतिष्ठित करके सॉफ्टवेयर इंजीनियरिंग को "बहु-व्यक्ति कार्यक्रमों के बहु-व्यक्ति विकास" के रूप में परिभाषित किया गया। , लेकिन डेविड पर्नास ने जोर देकर कहा)। उन्होंने निष्कर्ष निकाला कि यह क्षेत्र जितना परिपक्व हो गया है, उससे कहीं अधिक बढ़ गया है, यह सवाल करते हुए कि क्या हमने इसे इंजीनियरिंग अनुशासन कहे जाने के लिए पर्याप्त बनाया है, और किसी अन्य भाषा और अभी तक एक अन्य तकनीक का आविष्कार करने के लिए समुदाय का पीछा करते हुए।

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

मछली, कवर बैंड और स्लाइडशो

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

सॉफ्टवेयर इंजीनियरिंग डांस पार्टी!रॉबर्ट मैकक्लेर, 1968 नाटो सम्मेलन के उपस्थित लोगों में से एक।

शुक्रवार की सुबह, मुझे गुरुवार के संयोजक, रॉबर्ट मैकक्लेर के पैनल में से एक ने ब्रेक के दौरान अकेले बैठे पाया, और इसलिए मैंने एक बातचीत शुरू करने का फैसला किया। वह 1968 सम्मेलन के मूल उपस्थित लोगों में से एक थे, और प्रगति के लिए वकालत करने वाले उद्योग में एक सक्रिय विचार नेता थे। मैंने उनसे पूछा कि 50 वर्षों में क्या बदला है, क्या नहीं, और उनकी प्रगति की अवधारणा क्या है। हमारे पास सॉफ्टवेयर इंजीनियरिंग में कई बुनियादी मुद्दों के बारे में एक आकर्षक, विस्तृत बातचीत थी। उन्होंने सॉफ़्टवेयर के डिज़ाइन के बीच कुछ महत्वपूर्ण अंतरों पर चर्चा शुरू की (जो एक समस्या को समझने और इसके संदर्भ की आवश्यकता होती है), इंजीनियरिंग डिज़ाइन (जिसे किसी समाधान को ध्यानपूर्वक निर्दिष्ट करने की आवश्यकता होती है), और इंजीनियरिंग (जो उस विनिर्देश का शुद्ध कार्यान्वयन है)। रॉबर्ट ने सॉफ्टवेयर इंजीनियरिंग और अन्य इंजीनियरिंग विषयों के बीच तुलना की, इसलिए मैंने उनसे पूछा कि उनका मानना ​​है कि बुनियादी अंतर, यदि कोई हो। उन्होंने सुझाव दिया कि यह डिग्री का मामला है। मैंने अनुमान लगाया कि महत्वपूर्ण अंतर वह डिग्री था जिसके लिए एक डिजाइनर या इंजीनियरिंग डिजाइनर किसी समस्या या विनिर्देश की समझ में विश्वास कर सकते हैं; उस साइट को समझना जिस पर आप एक पुल का निर्माण करते हैं, वह प्राकृतिक विज्ञानों पर निर्भर करता है, जो कि एक हद तक अनुमानित है जो मानव, सामाजिक और संगठनात्मक प्रणालियों के लिए सच नहीं है, जिसके लिए सॉफ्टवेयर आमतौर पर डिज़ाइन किया गया है। आत्मविश्वास की यह कमी प्रोटोटाइप, प्रतिक्रिया और विकास की आवश्यकता पैदा करती है जो अन्य इंजीनियरिंग विषयों के लिए आवश्यक नहीं है (और यह भी संभव नहीं है)। हमने इन सभी कौशलों के लिए आवश्यक शिक्षा, और परिवर्तन की दर के बारे में भी बात की। उन्होंने पिछले 50 वर्षों में उनके देखे जाने की तुलना में बहुत अधिक परिवर्तन की उम्मीद की, और अनुमान लगाया कि मानव स्वभाव कभी भी विश्वास करने की तुलना में बहुत अधिक प्रतिरोधी है। मैंने सुझाव दिया कि यह प्रभावी शिक्षा की विफलता हो सकती है, 1968 में लगभग 10,000 डेवलपर्स से 2018 में 30 मिलियन तक की तेजी से वृद्धि के साथ संयुक्त। उन्होंने मुझे बदलाव के बारे में मेरी अपेक्षाओं को कम करने के लिए प्रोत्साहित किया; मैंने उनसे कहा कि एक तनु प्रोफेसर के रूप में, मैं अगले 40 वर्षों तक इसमें था, और धैर्य रखूंगा।

ब्रायन Randell, सॉफ्टवेयर इंजीनियरिंग इतिहासकार।

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

इवर एक कहानी के साथ अपना मुख्य विषय खोल रहा है।

यूएमएल और रैशनल यूनिफाइड प्रोसेस के प्रमुख योगदानकर्ता इवर जैकबसन ने एक शीर्षक दिया, "50 साल का सॉफ्टवेयर इंजीनियरिंग, तो अब क्या?" , वह सॉफ्टवेयर इंजीनियरिंग के बारे में कुछ नहीं जानता था। और फिर भी, उन्होंने अभी भी इतिहास में सबसे सफल स्वीडिश उत्पादों में से एक का नेतृत्व किया। सॉफ्टवेयर की सफलता की उनकी व्याख्या अंततः व्यवसाय मॉडल और डेवलपर्स के कारण है, न कि सॉफ्टवेयर और न ही प्रक्रिया। उनका विचार है कि 50 वर्षों के बाद, यह अभी भी एक इंजीनियरिंग अनुशासन से अधिक शिल्प है। वास्तव में, इतिहास में, उनका तर्क है कि हम विज्ञान की तुलना में फैशन से बहुत अधिक प्रेरित हैं: ऑब्जेक्ट-ओरिएंटेशन, यूएमएल, सीएमएमआई, एजाइल, और जो कुछ भी आगे है, वे सभी फैशन होंगे। आइवर का तर्क था कि सभी विधियां युद्ध विचलित कर रही हैं। इवर के अनुसार वास्तविक समस्या यह है कि विधियां वास्तव में प्रथाओं की रचनाएं हैं, और विधियां अखंड हैं और गुरुओं द्वारा संरक्षित जेलों में फंसी हुई हैं। इवर के विचार में, यह अपरिपक्व और मूर्खतापूर्ण है।

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

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

एंड्रियास ने अपने पुरस्कार की बात शुरू की

एंड्रियास ज़ेलर ने उनके SIGSOFT रिसर्च अवार्ड प्राप्त करने के तुरंत बाद मुझसे बात की। उन्होंने अपने करियर के बारे में तीन कहानियां दीं, सभी प्रभाव पर केंद्रित थीं। पहली कहानी उनकी पहली परियोजना और प्रस्तुति के बारे में थी जिसमें उन्होंने एक समस्या की तलाश में एक समाधान का योगदान दिया था। प्रतिक्रिया से निराश, उन्होंने GNU DDD डिबगर पर ध्यान केंद्रित करके पलटाव किया, जिसका वास्तविक व्यावहारिक प्रभाव था। उनका पहला प्रसंग यह था कि वास्तविक समस्याओं का पता लगाना बहुत आवश्यक था, लेकिन प्रभाव डालने का एक शानदार तरीका भी था। उनकी दूसरी कहानी सादगी के बारे में थी। एक सम्मेलन में किसी को घृणा थी कि डेल्टा डिबगिंग का उनका विचार इतना सरल था। इससे इंपोस्टर सिंड्रोम, बौद्धिक हीनता की भावना पैदा हुई। लेकिन उन्होंने समय के साथ महसूस किया कि सादगी शक्ति थी; जटिलता विफलता थी। उनकी अंतिम कहानी टॉम ज़िमरमैन के साथ खनन सॉफ्टवेयर रिपॉजिटरी पर काम शुरू करने के बारे में थी। उन्होंने देखा कि उनके शुरुआती काम के परिणामों के बारे में आशंकाएं बस इसलिए नहीं हुईं, क्योंकि यह तथ्य था कि काम नया था। नवाचार दुनिया के अंधेरे समझे जाने वाले लेकिन प्रासंगिक हिस्सों का अध्ययन करने के बारे में है। अंततः, एंड्रियास ने तर्क दिया कि केवल एक चीज जो वास्तव में मायने रखती है वह प्रभाव है। वह हमारे सपनों को आगे बढ़ाने और लगातार बने रहने के लिए एक प्रेरक पुकार के साथ समाप्त हुआ।

गोथेनबर्ग को अलविदा कहना, इस वर्ष के आईसीएसई में मेरे द्वारा सीखी गई सभी चीजों को संक्षेप में प्रस्तुत करना चुनौतीपूर्ण है। लेकिन चलो कुछ भी कोशिश करते हैं:

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

ये ऐसे सबक हैं जो हमारे समुदाय के प्रत्येक सदस्य को अंतत: आंतरिक करने चाहिए। हमें उनके महत्व का एहसास हुए 50 साल हो गए हैं, और हम केवल उन्हें गंभीरता से लेने की शुरुआत कर रहे हैं।