सॉफ्टवेयर डेवलपमेंट का सबसे कठिन हिस्सा coding नहीं, requirements हैं

 (stackoverflow.blog)
66 पॉइंट द्वारा xguru 2023-07-10 | 8 टिप्पणियां | WhatsApp पर शेयर करें
  • डेवलपर्स को AI से replace करना मुश्किल क्यों है
  • कई खबरों में कहा जाता है कि AI डेवलपर्स की जगह ले लेगा, लेकिन सॉफ्टवेयर बनाने में सबसे कठिन हिस्सा coding नहीं बल्कि स्पष्ट और सटीक requirements बनाना है
  • "वह bug नहीं, feature है। ओह, एक मिनट, वह bug है"
    • अस्पष्ट requirements bugs पैदा करती हैं
  • "अगर AI को डेवलपर्स की जगह लेनी है, तो clients को ठीक-ठीक बताना होगा कि उन्हें क्या चाहिए। हम सुरक्षित हैं"

AI की हकीकत: chess vs. autonomous vehicles

  • AI का उपयोग chess जैसे सीमित और स्पष्ट नियमों वाले क्षेत्रों में सफलतापूर्वक हुआ है, लेकिन autonomous vehicles AI के लिए कहीं अधिक जटिल चुनौती हैं क्योंकि उनमें अनंत variables और exception situations होती हैं
  • टेक इंडस्ट्री में 5 nines या 6 nines availability का standard है (99.999% से 99.9999%)
    • 99% तक पहुँचना बहुत महंगा नहीं होता। 99% का मतलब है कि आपकी website साल में 3 दिन से कम समय के लिए down रहेगी (87.6 घंटे)
    • लेकिन हर अतिरिक्त 9 के साथ वहाँ तक पहुँचने की लागत exponential रूप से बढ़ती है
    • 99.9999% पाने के लिए साल भर में केवल 31.5 सेकंड downtime होना चाहिए (99.9% = 526 मिनट/8.76 घंटे, 99.99% = 52 मिनट, 99.999% = 5.2 मिनट)
    • इसके लिए बहुत भारी planning और effort चाहिए, और जाहिर है यह महंगा होता है
  • AI चाहे जितना बेहतर हो जाए, accidents का जोखिम हमेशा रहेगा
  • हमें नहीं पता कि कितने स्तर तक accidents स्वीकार्य होंगे, लेकिन कम से कम इंसानों जितना अच्छा तो होना ही चाहिए

AI सॉफ्टवेयर नहीं बना सकता, सिर्फ code बना सकता है

  • सॉफ्टवेयर बनाना और maintain करना chess की तुलना में driving से कहीं ज़्यादा मिलता-जुलता है
  • इसमें अनगिनत variables होते हैं, और rules judgment के आधार पर तय होते हैं
  • सॉफ्टवेयर बनाते समय चाहा गया outcome होता है, लेकिन वह chess जितना simple नहीं होता
  • सॉफ्टवेयर लगभग कभी truly complete नहीं होता। यह एक ongoing exercise है जिसमें लगातार features जुड़ते हैं और bugs fix होते रहते हैं
  • सॉफ्टवेयर के विपरीत, chess game जीत या हार के साथ खत्म हो जाता है
  • सॉफ्टवेयर डेवलपमेंट में हमारे पास सॉफ्टवेयर design को chess के rules engine जैसा बनाने का एक tool है: technical specs
  • सबसे अच्छे हालात में ये technical specs user behavior और program flow का अनुमान लगाती हैं
  • लेकिन ऐसा बहुत कम होता है। अक्सर हमें feature spec की जगह wishlist मिलती है, या नैपकिन पर बने wireframes, या अस्पष्ट requirements documents दे दिए जाते हैं और कहा जाता है कि हम अपनी best judgment लगाएँ
  • और भी बुरी बात यह है कि requirements बदलती भी रहती हैं और कई बार नज़रअंदाज़ भी कर दी जाती हैं
    • असंभव requirements। मूल लेख में एक ऐसे project का उदाहरण है जिसमें बिना WiFi वाले क्षेत्र में text messages के जरिए COVID survey कराने की बात थी। उसे न करना ही सही था
    • क्या AI वाकई ऐसी situations को संभाल पाएगा?
  • AI के लिए functional software बनाना तभी संभव होगा जब हम वास्तव में जानें कि हमें क्या चाहिए और उसे स्पष्ट व सटीक रूप से define कर सकें
  • पिछले 10 वर्षों में software industry waterfall से agile approach की ओर शिफ्ट हुई है
    • waterfall में stakeholders को लगता था कि वे जानते हैं कि उन्हें क्या चाहिए और उसे document कर सकते हैं, लेकिन final product मिलने पर वे बहुत निराश होते थे, इसलिए वह model असफल रहा
    • agile इस process का समाधान है
  • AI हमारे पास पहले से मौजूद software को modern hardware और नई languages में rewrite करने के लिए सबसे उपयुक्त हो सकता है
    • अभी भी कई जगह COBOL में लिखा software इस्तेमाल होता है, लेकिन उस language को सीखने वाले लोग बहुत कम हैं
  • AI शायद पहले से बने हुए software को इंसानों से तेज़ी से बना सके, लेकिन ऐसा इसलिए है क्योंकि किसी ने पहले ही यह सोच लिया था कि वह software कैसे बनाया जाना चाहिए
  • अगर हम उस waterfall process का इस्तेमाल करें जिसे हम death march कहते हैं, तो AI काफी अच्छी तरह software बना सकता है
    • waterfall में सबसे खराब कौन है? इंसान
    • सिर्फ वह हिस्सा नहीं जहाँ programming team को सौंपने के लिए document लिखा जाता है, बल्कि उससे पहले की पूरी प्रक्रिया
  • AI कुछ चौंकाने वाली चीज़ें कर सकता है, लेकिन वह आपका मन नहीं पढ़ सकता और न ही आपको बता सकता है कि आप क्या चाहते हैं

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

8 टिप्पणियां

 
pmc7777 2023-07-12

मुझे लगता है कि यह केवल software development ही नहीं, बल्कि उन सभी क्षेत्रों पर लागू होता है जहाँ AI को लेकर चिंताएँ हैं।
 
botplaysdice 2023-07-11

लगता है requirements validation को automate करने वाली तकनीकें काफ़ी आगे बढ़ेंगी। test automation की अहमियत और भी ज़्यादा नज़र आएगी... क्या अब ऐसा दौर आने वाला है जहाँ इंसान सिर्फ़ test case ही manage करेगा....
 
dkang 2023-07-10

"Waterfall में कौन सबसे भयानक है? इंसान।"
खुद यह झेला है, इसलिए पूरी तरह सहमत हूँ
 
hyeonseok 2023-07-10

अच्छा लेख पढ़ लिया है, अब चलिए issue को व्यवस्थित करने चलते हैं।
 
eususu 2023-07-10

भले ही AI के लिए डेवलपर्स की जगह लेना मुश्किल हो, लेकिन अगर डेवलपर सिर्फ keywords दे दें, तो क्या coding AI कर सकती है?
पहले जिसे मज़ाक में कहा जाता था, वह voice coding शायद अब हक़ीक़त बन जाए..
 
neidn 2023-07-12

क्या आजकल copilot या दूसरे AI का इस्तेमाल करके डेवलपमेंट ऐसे नहीं करते?
अगर कमेंट में ज़रूरी बात अंग्रेज़ी में लिख दें, तो वह अपने-आप बना देता है, और फिर बस यह चेक करना होता है कि वह हमारी इच्छा के मुताबिक है या नहीं।
 
ethanhur 2023-07-10

मैं इससे बहुत सहमत हूँ। मेरा मानना है कि भविष्य के सभी software engineers के पास TPM जैसी क्षमताएँ होंगी, और उनसे इसकी अपेक्षा भी की जाएगी।
 
2023-07-10
[यह टिप्पणी छिपाई गई है.]