सॉफ़्टवेयर संकट

 (wryl.tech)
1 पॉइंट द्वारा GN⁺ 2024-07-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें

सॉफ़्टवेयर संकट

  • सॉफ़्टवेयर संकट क्या है?

    • 1968 की पहली NATO Software Engineering Conference में "software crisis" शब्द का पहली बार उपयोग हुआ
    • ये सम्मेलन programming practices को परिभाषित और व्यवस्थित करने की शुरुआती कोशिशों में से एक थे
    • 1969 में Apollo 11 के प्रक्षेपण के समय के आसपास अंतिम NATO Software Engineering Conference आयोजित हुई

  • सॉफ़्टवेयर संकट के कारण

    • 1972 के Turing Award विजेता Edsger Dijkstra ने सॉफ़्टवेयर संकट का कारण hardware की बढ़ती जटिलता और गति को बताया
    • "जैसे-जैसे मशीनें अधिक शक्तिशाली होती हैं, programming problems भी बढ़ती हैं" - Edsger Dijkstra

  • वर्तमान सॉफ़्टवेयर संकट

    • आजकल सॉफ़्टवेयर संकट का ज़िक्र कम किया जाता है
    • नई languages और संगठन के तरीकों के विकास के कारण लोग मानते हैं कि समस्या हल हो गई है
    • लेकिन यह वास्तविक सहजता के बजाय हार और स्वीकार्यता की भावना से पैदा हुआ हो सकता है

  • abstraction की समस्या

    • सॉफ़्टवेयर संकट को हल करने के लिए कई प्रयास हुए, लेकिन उनमें से अधिकांश ने "abstraction" के ज़रिए समस्या सुलझाने की कोशिश की
    • abstraction कुछ हद तक स्वतंत्रता देता है, लेकिन इसकी कीमत performance में चुकानी पड़ती है
    • personal computer के व्यावसायीकरण के बाद abstraction बुनियादी सोच का तरीका बन गया

  • developer और user के बीच की खाई

    • सॉफ़्टवेयर संकट सिर्फ सॉफ़्टवेयर बनाने वालों को नहीं, बल्कि उसका उपयोग करने वालों को भी प्रभावित करता है
    • user के पास author द्वारा दिए गए विकल्पों के अलावा लगभग कोई नियंत्रण नहीं होता
    • Alan Perlis: "अगर आपके पास कोई अच्छा विचार है, तो उसके लिए ज़िम्मेदारी लेने के लिए तैयार रहना चाहिए"

  • ज़िम्मेदारी का अभाव

    • सॉफ़्टवेयर निर्माता अपने बनाए हुए tools की ज़िम्मेदारी से अलग हो गए हैं
    • व्यावसायीकरण के साथ यह प्रवृत्ति और मजबूत हुई
    • abstraction का उपयोग कठिन सोच से बचने के साधन के रूप में किया जाता है

  • समाधान

    • सॉफ़्टवेयर संकट का समाधान अधिक सीमित platforms पर लौटना नहीं, बल्कि abstraction layers की संख्या सीमित करना और information preservation की मांग करना है
    • programming model, user interface, और underlying hardware उथले और composable होने चाहिए
    • tools के users को अधिकार और नियंत्रण दिया जाना चाहिए

  • वर्तमान आंदोलन

    • Handmade, Permacomputing, retro computing आदि जैसे आंदोलन सॉफ़्टवेयर संकट के प्रति जागरूकता बढ़ाने का काम कर रहे हैं
    • ये counterculture movements एक स्वस्थ संकेत हैं और बताते हैं कि स्थिति बेहतर हो सकती है

GN⁺ की संक्षिप्त प्रस्तुति

  • सॉफ़्टवेयर संकट hardware की बढ़ती जटिलता और गति के कारण पैदा हुई समस्या है
  • आज इसे abstraction के ज़रिए हल करने की कोशिश की जा रही है, लेकिन इसकी कीमत performance में चुकानी पड़ती है
  • सॉफ़्टवेयर निर्माता अपने बनाए tools की ज़िम्मेदारी से दूर हैं, और व्यावसायीकरण ने इसे और बढ़ाया है
  • समाधान abstraction layers की संख्या सीमित करने और information preservation की मांग करने में है
  • Handmade और Permacomputing जैसे आंदोलन सॉफ़्टवेयर संकट के प्रति जागरूकता बढ़ा रहे हैं

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

1 टिप्पणियां

 
GN⁺ 2024-07-07
Hacker News की राय

  • लेखक की राय

    • abstraction के ख़िलाफ़ नहीं, बल्कि उसके असीमित इस्तेमाल के ख़िलाफ़ हैं
    • अधिक सीमित platforms की ओर लौटने को समाधान नहीं मानते
    • यह नहीं कहते कि users को "ज़्यादा technical" होना चाहिए
    • software crisis को समझने के लिए "platform proficiency" और "growth/release cycle" curves को समझना ज़रूरी है
    • यह लेख clickbait नहीं है, बल्कि developer के रूप में स्थिति का प्रतिबिंब है
    • समस्या के समाधान का एक हिस्सा देना चाहते हैं, और आगे follow-up लेख लिखने की योजना है

  • software crisis

    • इसमें project budget का बढ़ जाना, schedule delay, inefficient software, low quality, requirements पूरी न होना, maintenance में कठिनाई, और software deliver न हो पाना जैसी समस्याएँ शामिल हैं
    • सफल software को नज़रअंदाज़ कर दिया जाता है, और सिर्फ़ failures और defects पर ध्यान दिया जाता है
    • computers के desktop तक पहुँचने से पहले सैकड़ों abstractions से गुजरना पड़ता है, और यह दुनिया भर में हर दिन अरबों बार होता है

  • software development और leadership

    • automobile company leadership technical knowledge पर ज़ोर देती है, लेकिन agile software development में technical capability निचले स्तरों पर ही रुक जाती है
    • software developers दार्शनिक विचार के बिना ticket-by-ticket काम करते हैं, और leadership roles में promote नहीं होते
    • software crisis की समझ शायद hobby गतिविधियों तक ही सीमित रह जाती है

  • abstraction की ज़रूरत

    • abstraction एक ज़रूरी tool है, और समस्या बुरी abstractions या बहुत ज़्यादा abstractions हैं
    • software development पहले से आसान हुआ है, और documentation भी अच्छी है

  • tools और information

    • सही tools का पता हो तो software development बहुत आसान है
    • ज़्यादातर लोगों को जिन tools की जानकारी है, वे अच्छे नहीं हैं, और इस पर capital का प्रभाव है
    • उदाहरण के लिए, serverless environment में 3 घंटे में एक complex marketplace app बनाकर दिखाने वाला वीडियो बनाया, लेकिन views बहुत कम आए

  • GUI और composability

    • UNIX tools का इस्तेमाल करते समय एक shallow और composable experience मिलता है
    • GUI एक-दूसरे से communicate नहीं करते और composable नहीं होते
    • GUI और shell pipelines को मिलाने वाले tools पर प्रयोग कर रहे हैं

  • software का महत्व

    • ज़्यादातर software mission-critical नहीं है, इसलिए low quality भी हमेशा बड़ा मुद्दा नहीं बनती
    • अधिकांश software developers Silicon Valley जैसी motivation के बिना काम करते हैं

  • modularity और abstraction

    • internet जैसे complex systems layered abstractions के सहारे बने रहते हैं
    • software tools में 70s के बाद से काफ़ी बड़ा सुधार हुआ है
    • उदाहरण के लिए, VSCode के copilot का उपयोग करके पूरा API auto-complete किया जा सकता है

  • project management crisis

    • software crisis से ज़्यादा project management crisis मौजूद है
    • planning करने वालों और delivery करने वालों के बीच gap है
    • software development के commercialization की वजह से अलग-अलग स्तर के लोग इसमें शामिल हो सकते हैं
    • यह food industry जैसा है; इसे restaurant crisis नहीं कहा जाता