हम विशेष नहीं हैं (2021)

 (hillelwayne.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • केवल software की विशेषता माने जाने वाले requirements changes और uncertainty, दोहराव वाले काम और अस्थायी जुगाड़ पारंपरिक engineering में भी आम हैं, और दोनों क्षेत्रों में फर्क से ज़्यादा समानताएँ हैं
  • पारंपरिक engineering = Waterfall, software = Agile जैसी विभाजन रेखा बहुत अधिक सरल बना देती है। physical निर्माण में iteration की लागत अधिक होती है, इसलिए पहले से design ज़्यादा होता है, लेकिन tunnel, civil, और electronics क्षेत्रों में भी incremental development और on-site adaptation का उपयोग होता है
  • supplier के बंद हो जाने, manufacturing equipment के बदलने, या मिट्टी की अप्रत्याशित विशेषताओं जैसी समस्याएँ पारंपरिक engineering में भी योजनाएँ उलट सकती हैं, इसलिए केवल software को ही खास तौर पर unpredictable कहना मुश्किल है
  • असली फर्क software की उच्च consistency और तेज़ बदलाव की क्षमता, तथा अपेक्षाकृत लचीली constraints में है। physical products को material variation, wear, strength और size जैसी hard constraints, और ऐसे बदलाव झेलने पड़ते हैं जिन्हें पलटना आसान नहीं होता
  • तेज़ modifications से experiment और validation आसान हो जाते हैं, लेकिन इससे physical defects को code से workaround करने का दबाव भी बन सकता है। हर engineering क्षेत्र दूसरे से design, validation, और automation के तरीके सीख सकता है

software के विशेष होने का बचाव तर्क

  • oil reservoir तेल से भरा गुब्बारा नहीं, बल्कि porous rock structure होता है, इसलिए अचानक pressure loss होने पर यह तय करना मुश्किल होता है कि वजह कोई स्थानीय खाली जगह है या समुद्र तक खुला रास्ता
    • धीरे-धीरे भरने और pressure balance करने के लिए छोटी खाली जगहों में hazelnut shells डाली जाती हैं, और इससे यह भी परखा जाता है कि वह उसी संरचना के भीतर है या नहीं
    • नॉर्वे में oil companies का hazelnut shells का सबसे बड़ा खरीदार होना यह दिखाता है कि पारंपरिक engineering भी अनपेक्षित materials और field response पर निर्भर करती है
  • software और पारंपरिक engineering की तुलना करते समय license या कठोरता के अंतर के आधार पर software को engineering से कमतर माना जाता है, और साथ ही उसे ऐसा विशेष क्षेत्र भी बना दिया जाता है जिसे सामान्य engineering ढाँचे में समझा ही नहीं जा सकता
  • यह तर्क कि requirements बहुत तेज़ी से बदलती हैं, इसलिए पहले से planning और engineering methods लागू करने की ज़रूरत नहीं, एक defensive mechanism की तरह काम करता है
    • NoEstimates movement का लक्ष्य यह है कि software estimation, पारंपरिक engineering से अलग, इतना कठिन है कि estimation को ही हटा दिया जाए
  • लेकिन software में जिन समस्याओं को हम बेहद दर्दनाक मानते हैं, उनमें से ज़्यादातर दूसरी engineering disciplines में भी मौजूद हैं, और दोनों तरह का काम कर चुके engineers मानते हैं कि दोनों की प्रकृति काफ़ी करीब है

अक्सर बताए जाने वाले पाँच अंतर

  • अगर पूरी पारंपरिक engineering को एक ही क्षेत्र की तरह देखा जाए, या उसे civil engineering के बराबर मान लिया जाए, तो उसके भीतर के अलग-अलग subfields के अंतर गायब हो जाते हैं
  • software और पारंपरिक engineering के बीच आम तौर पर बताए जाने वाले सामान्य अंतर ये हैं
    • पारंपरिक engineering Waterfall के लिए, software Agile के लिए उपयुक्त है
    • पारंपरिक engineering predictable है, लेकिन software का अनुमान लगाना कठिन है
    • engineering मुख्यतः manufacturing है और code design है, इसलिए “code ही design है”
    • पारंपरिक engineering software engineering से अधिक कठोर है
    • software पारंपरिक engineering से बहुत तेज़ चलता है
  • इनमें कुछ जगह वास्तविक अंतर हैं, लेकिन ज़्यादातर दावे ग़लत हैं या निर्णय के लिए ज़रूरी मुख्य संदर्भ गायब है

Waterfall और Agile का सरल विभाजन

  • प्रचलित कहानी के अनुसार Winston Royce ने 1970 में building process से प्रेरित होकर Waterfall बनाया, और requirements changes के प्रति कमज़ोर इस पद्धति को 2001 में Agile Manifesto ने बदल दिया
  • वास्तविक Waterfall आज की धारणा जितना कठोर या सार्वभौमिक नहीं था
    • 1970~1980 के दशक में developers ad hoc planning या Spiral Model, V Model जैसे कई incremental models का उपयोग करते थे
    • Agile कोई पूरी तरह अलग क्रांति कम, और उस समय के प्रवाह का स्वाभाविक परिणाम ज़्यादा था
  • यह सच है कि पारंपरिक engineering पहले से design और अलग testing time ज़्यादा रखती है, लेकिन इसका कारण Waterfall की कठोरता से ज़्यादा iteration cost की अर्थव्यवस्था है
    • जब iteration में समय और पैसा अधिक लगता है, तब एक बार के काम को ज़्यादा देर तक plan करना तर्कसंगत होता है
    • अगर circuit board शुरू से काम न करे, तो उसे फिर से factory भेजना पड़ सकता है, जिससे हज़ारों pounds और 2 हफ़्ते की अतिरिक्त देरी हो सकती है
  • design और implementation की सीमा भी स्पष्ट नहीं होती
    • civil engineer का scale model, या automobile engineer द्वारा aesthetics और aerodynamics जाँचने के लिए बनाया गया clay full-scale model, design भी माना जा सकता है और implementation भी
  • दूसरे industries में भी Agile जैसी पद्धतियाँ मौजूद हैं
    • Austrian tunnel method iteration-based development और on-site improvisation पर निर्भर करती है
    • Handbook of Industrial Engineering departments के बीच collaboration और तेज़ customer feedback पर ज़ोर देती है
    • civil engineering में भी construction शुरू होने के बाद field issues संभालने के लिए खुली communication और adaptation पर ज़ोर बढ़ जाता है

पारंपरिक engineering का अनुमान लगाना भी कठिन है

  • तैयार bridge या product को देखकर, उसके पीछे हुए friction, cost overruns, और delays को नज़रअंदाज़ करना आसान है
    • दीवार 1 inch ग़लत खड़ी हो जाए, या कोई महत्वपूर्ण supplier बंद हो जाए, तो भी पूरी योजना हिल सकती है
  • software में भले ऐसा लगे कि हर 1~2 साल में dominant framework या language बदल जाती है, लेकिन पारंपरिक engineering में भी tools और production environment के बदलाव आते हैं
    • जब semiconductor foundry नया manufacturing equipment लाती है, तो chip design plan भी बदल सकता है
    • यह library जितनी तेज़ी से नहीं बदलता, लेकिन इसका मतलब बदलाव न होना नहीं है
  • construction के दौरान ownership बदल जाना, verified process का अचानक स्थायी रूप से विफल होना, या development के आख़िरी चरण में नए तथ्य सामने आना भी संभव है
  • यदि bridge foundation का काम शुरू होने के बाद पता चले कि कोई मिट्टी अपेक्षा से अलग जमती है और भूकंप में ज़रूरत से ज़्यादा liquefy हो जाती है, तो design को फिर से शुरू करना पड़ सकता है
  • यह सोचना कि केवल software ही विशेष रूप से unpredictable है, दूसरे engineering क्षेत्रों के वास्तविक काम को न देखने से पैदा होता है

“code ही design है” वाला दावा

  • “code ही design है” यह उस सोच के विरुद्ध प्रतिक्रिया थी कि UML में perfect model बना लेने के बाद code अपने-आप generate किया जा सकता है
  • CPython core developer और पूर्व Boeing systems integration engineer Nick Coghlan इसे software और अपने पहले के काम के बीच मूलभूत अंतर नहीं मानते
    • उन्होंने aircraft, air traffic control, और antenna array जैसे कई स्वतंत्र system teams के बीच compatible interfaces बनवाने के लिए समन्वय किया
  • semiconductor engineer के लिए CPU के शुरुआती schematic से लेकर foundry से निकले अंतिम chip तक पूरा process design ही है, और manufacturing अपेक्षाकृत सरल चरण हो सकता है जहाँ design सौंपकर chip प्राप्त की जाती है
  • यदि तैयार chip या mechanical product में defect हो, तो design बदलना पड़ता है; इसलिए design और production अलग-अलग नहीं हैं
    • mechanical engineering में “fettling” का मतलब production process की छोटी imperfections के हिसाब से design को समायोजित करना है
    • production design को बदलता है, और बदला हुआ design फिर production को बदलता है — यह एक चक्र है
  • design की सीमा भी अपने-आप में अस्पष्ट है
    • architectural overview, formal specification, और detailed drawings — ये सब design के अलग-अलग स्तर हैं
    • bridge drawings जैसे complex projects में कई स्तरों पर दोहराए जाने वाले details होते हैं
  • construction पर सबसे अधिक समय और पैसा खर्च होना bridge/building-केंद्रित civil engineering के कुछ हिस्सों की विशेषता है; इसे पूरी पारंपरिक engineering का प्रतिनिधि रूप नहीं माना जा सकता
  • civil engineering भी शहर निर्माण के लिए ज़रूरी कई क्षेत्रों को समेटती है, इसलिए उसे सिर्फ bridge और building तक सीमित नहीं किया जा सकता

कठोरता को लेकर ग़लतफ़हमी

  • यह विभाजन कि पारंपरिक engineering first principles से सावधानी से reasoning करती है, जबकि software copy-paste पर निर्भर है, वास्तविक काम को ठीक से नहीं दर्शाता
  • software में अपेक्षाकृत कम दिखने वाली कठोरता केवल culture की समस्या नहीं, बल्कि ऐसे material गुणों पर आधारित तर्कसंगत समझौता भी हो सकती है जहाँ implementation और testing आसान होती है
    • कई बार assumptions जाँचने का सबसे आसान तरीका सीधे implement करके चलाना होता है
    • अनुभवजन्य जानकारी जल्दी इकट्ठा करना भी अपने-आप में कठोर validation का तरीका है
  • यह मान लेना भी सही नहीं कि पारंपरिक engineering products software से ज़्यादा consistent और systematic होते हैं
    • record keeping और comprehensive validation में software कई बार आगे होता है
    • पारंपरिक engineering की महत्वपूर्ण जानकारी अक्सर Excel files या पुराने filing cabinets में पड़ी रहती है और पुरानी या क्षतिग्रस्त हो जाती है
    • बहुत से पारंपरिक engineers वे automated tests अपनाना चाहते हैं जिन्हें software में सामान्य माना जाता है
  • physical structures में भी ज़रूरत पड़ने पर bracket जोड़ने जैसे अस्थायी जुगाड़ लगातार इस्तेमाल होते हैं

वास्तविक अंतर 1: consistency

  • software पूरी तरह logic से बना होता है और spring की तरह घिसता नहीं, इसलिए यह दूसरी engineering outputs की तुलना में कहीं अधिक consistent होता है
    • यदि कोई sorting function असामान्य input नहीं, बल्कि सामान्य संख्या सूची का सिर्फ 95% ही sort करे, तो उसे सामान्य व्यवहार मानना कठिन है
  • physical materials और parts में सैद्धांतिक मान से विचलन मूलभूत रूप से मौजूद होता है
    • resistors 1Ω से लेकर सैकड़ों मिलियन Ω तक उपलब्ध होते हैं, और उनके color bands सैद्धांतिक resistance value दर्शाते हैं
    • हरा-नीला-लाल band 5,600Ω दर्शाता है, लेकिन यदि gold tolerance band हो, तो वास्तविक मान 5% तक अलग हो सकता है
    • एक ही resistor के 100 pieces में कुछ 5,320Ω और कुछ 5,880Ω हो सकते हैं, इसलिए हर एक को मापना पड़ सकता है
    • wear और temperature changes को जोड़ लें तो variation और जटिल हो जाता है
  • लगभग सभी physical materials में इसी तरह की समस्याएँ होती हैं, और screw manufacturer Fastenal भी चेतावनी देता है कि stainless steel screws को aluminium plate में इस्तेमाल न करें

वास्तविक अंतर 2: बदलाव की गति

  • software को दूसरे engineering systems की तुलना में कहीं अधिक तेज़ी से बदला जा सकता है
    • पारंपरिक engineering में specification साझा करने के बाद factory या machine shop में fabrication, installation, और कई हफ़्तों की testing का इंतज़ार करना पड़ता है
    • कुछ engineering changes में हर बार budget से $5,000 का स्पष्ट खर्च घट जाता है
    • code बदलने के बाद पूरा test suite सेकंडों में चलाया जा सकता है
  • non-software क्षेत्रों में chemical engineering इसकी गति के सबसे करीब दिखी, लेकिन वहाँ भी 1-minute scale पर बदलाव की कल्पना करना कठिन है
  • दूसरे engineering क्षेत्रों में design tools और simulation के लिए software का बढ़ता उपयोग भी इसी कारण है कि implementation से पहले ideas का prototype जल्दी बनाया जा सके
  • तेज़ बदलाव की क्षमता का नकारात्मक पहलू भी है
    • जब electronic या mechanical device की समस्या पूरी तरह हल नहीं होती, तो अक्सर software engineers पर code workaround से उसे ढकने का दबाव आता है
  • यह निर्भरता घातक परिणाम ला सकती है
    • 2019 में Boeing 737 MAX के दो crash में 300 से अधिक लोगों की मौत हुई
    • जाँच में automatic flight control system MCAS के bug को कारण बताया गया
    • Boeing ने बाद में सामने आई aircraft की aerodynamic characteristics की समस्या को physical design से ठीक करने के बजाय MCAS जोड़ दिया

वास्तविक अंतर 3: constraints और irreversible changes

  • पारंपरिक engineering products में weight, strength, resistance, और temperature जैसी physical limits होती हैं जिन्हें हर हाल में मानना पड़ता है
    • chip design में nanosecond के अंश जितने timing margins तक दूसरे teams के साथ negotiate करना पड़ सकता है
  • software में भी memory capacity, sensor की 10-cycle response, या API call limits जैसी constraints होती हैं
  • लेकिन software constraints अक्सर soft constraints होती हैं, जहाँ सीमा पार करने पर स्थिति धीरे-धीरे ख़राब होती है; इसलिए development speed या simple algorithm के लिए boundary थोड़ा खिसकाई जा सकती है
  • पारंपरिक engineering की constraints अक्सर hard constraints होती हैं; सीमा पार होते ही product काम नहीं करता
    • अगर box थोड़ा भी ज़्यादा चौड़ा हो, तो वह दरवाज़े से नहीं निकल सकता
  • oil drilling facility में लगाने वाले screw conveyor का एक उदाहरण था जो कमरे से कुछ inches ऊँचा निकला; equipment को छोटा नहीं किया जा सकता था, और ऊपर की चार मंज़िलों के कारण ceiling भी नहीं उठाई जा सकती थी
    • इसलिए ceiling में छेद किया गया, equipment को उसमें से निकाला गया, और ऊपर चलने वाले लोगों के गिरने से बचाने के लिए छेद के चारों ओर एक box लगाया गया
    • यह बदलाव facility की structure में स्थायी रूप से रह गया और बाद के हर बदलाव में उसे ध्यान रखना पड़ा
  • software engineer अस्थायी workaround वापस ले सकता है, लेकिन पारंपरिक engineering के physical workarounds अक्सर स्थायी संरचनाएँ बन जाते हैं

अलग है, पर विशेष नहीं

  • software की अपनी security समस्याएँ हैं, लेकिन civil engineering में मौसम और chemical engineering में chemical properties जैसी अलग चुनौतियाँ हर discipline में होती हैं
  • सभी engineering fields पहले से की गई abstract thinking, व्यवस्थित काम, और उचित जुगाड़ को महत्व देती हैं, और बदलती requirements तथा अज्ञात unknowns का सामना करती हैं
  • हर field काफ़ी हद तक अलग-थलग है; जिस तरह software engineer mechanical engineering को नहीं जानता, वैसे ही chemical engineering का engineer भी अन्य engineering fields के वास्तविक काम को समझना कठिन पाता है
  • software विशेष नहीं है, इसलिए यह दूसरी engineering fields से सुधार के तरीके सीख सकता है; और record keeping, validation, तथा automation जैसी चीज़ों में पारंपरिक engineering भी software से सीख सकती है
  • अगला लेख engineering हमें क्या सिखा सकती है, और हमसे क्या सीख सकती है दोनों पक्षों के बीच अदला-बदली किए जा सकने वाले ठोस सबक़ों पर चर्चा करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय

  • लेख के काफ़ी हिस्से से सहमत हूँ, लेकिन software engineering की rigor को लेकर यह ज़रूरत से ज़्यादा आशावादी है। आज भी automated testing, ख़ासकर कई परतों वाली मज़बूत testing, development process का स्वाभाविक हिस्सा नहीं है, और कहीं developer को ही इकलौता gatekeeper मान लिया जाता है या organization process को बाधा समझकर हटा देती है
    इंडस्ट्री हर कुछ साल में बिना सिद्ध best practices को व्यवस्थित किए फिर से पहिया ईजाद करती रहती है। जो standardized दिखता भी है, वह अक्सर बस एक ढीली-ढाली साझा शब्दावली होता है जिसका मतलब हर कंपनी में काफ़ी अलग होता है; agile और testing इसके अच्छे उदाहरण हैं। बहुत से developers testing को सिर्फ unit test तक सीमित मानते हैं, कुछ लोग component·integration test भी शामिल करते हैं, लेकिन कुछ कंपनियों में इतना करके ही production environment में deploy कर दिया जाता है
    जैसा कि मैंने पहले टिप्पणी में लिखा था, स्वस्थ organization में code review गुणवत्ता के लिए ज़िम्मेदार कई प्रक्रियाओं में से एक होना चाहिए, न कि production deployment तय करने वाला एकमात्र gate। बहुत सी teams और कंपनियों में merge के बाद की quality assurance process लगभग गायब है
    बात ज़िम्मेदारी को धुंधला करने की नहीं है, बल्कि code लिखने से पहले ही quality को process में समाहित करने की है। इसके लिए Three Amigos sessions, जहाँ अलग-अलग भूमिकाओं के लोग specifications और requirements पर चर्चा करें, test-driven development, IDE और हर gate में integrated static analysis, तथा developer से अलग quality assurance और test automation specialists की ज़रूरत होती है
    civil engineering में एक ही व्यक्ति पुल का designer, builder और इकलौता ज़िम्मेदार नहीं होता। वहाँ calculations और documentation, rechecking, government approval, construction के दौरान audit और inspection जैसी कई परतें होती हैं, और एक single-family house भी drawings, approvals, permits और inspections से गुज़रता है। engineering disasters भी अक्सर पूरी process की विफलता होते हैं, जहाँ कई चरणों पर रोकथाम नहीं हो पाती
    अगर software development की तुलना civil engineering से करनी है, तो यह भी मानना होगा कि process का स्तर बिल्कुल एक जैसा नहीं है। ज़्यादा से ज़्यादा, यह अक्सर ऐसे housing developer के क़रीब होता है जो कानूनी requirements को बायपास करते हुए सबसे सस्ता घर बनाता है

    • असली engineering क्षेत्रों में भी testing उम्मीद से बहुत कम होती है, और integration hell भी बेहद दर्दनाक होता है
    • अच्छा होता अगर software industry quality को ज़्यादा महत्व देती, लेकिन दोनों क्षेत्रों में failure cost ही अलग है। पुल की calculation ग़लत हो जाए तो लोग मर सकते हैं और नया पुल बनाए बिना उसे ठीक करना मुश्किल होता है, जबकि software defects अपवादस्वरूप जान-माल का नुकसान पहुँचा सकते हैं, पर आम तौर पर उन्हें ठीक किया जा सकता है
      इसलिए MRI control software जैसे क्षेत्रों को छोड़कर सामान्य software में testing/verification की लागत और उसके प्रभाव के बीच का संतुलन civil engineering से अलग होना ही है

  • तीनों लेख बेहतरीन हैं, पढ़ने की सलाह दूँगा। पुरानी चर्चाएँ भी साथ में देखी जा सकती हैं
    https://lobste.rs/s/fv8swh/crossover_project (project announcement)
    https://lobste.rs/s/lmvroa/are_we_really_engineers (फिर से चर्चा)
    https://lobste.rs/s/8j8sdc/are_we_really_engineers (एक और पुनर्चर्चा)
    Glenn Vanderburg का यह talk भी काफ़ी प्रासंगिक है

  • software development और पारंपरिक engineering के बीच सबसे बड़ा फ़र्क बदलाव के साथ आने वाला friction है। software को तुलनात्मक रूप से कम लागत पर बदला जा सकता है, और उसकी लचीलेपन से बिल्कुल नई संभावनाएँ खुलती हैं
    पारंपरिक engineering भी जितनी ज़्यादा simulations बनाती है, उतना ही वह physical और chemical सीमाओं के भीतर software जैसी changeability का दायरा बढ़ा सकती है
    “आप यह उम्मीद नहीं करते कि कोई sorting function 95% संभावना के साथ ही सामान्य संख्या-सूची को sort करेगा” — यह बात अब LLM-generated code पर सचमुच लागू होती है। ज़्यादातर समय काम करता है, लेकिन हर बार नहीं

  • ~hwayne ने account क्यों deactivate किया, यह जानने की जिज्ञासा है