YAGNI ने जिस लागत की कभी बात नहीं की

 (newsletter.kentbeck.com)
3 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • YAGNI केवल “अभी ज़रूरत नहीं है तो कोड मत लिखो” वाला साधारण बचत नियम नहीं है, बल्कि यह उस लागत पर बात करता है जो तब पैदा होती है जब ज़रूरत तय होने से पहले अनुमान के आधार पर architecture पहले से तय कर लिया जाता है
  • समस्या का केंद्र design खुद नहीं, बल्कि design कब करना है यह है; बहुत जल्दी structure बना देना, बहुत देर से structure बनाने जितना ही जोखिम भरा हो सकता है
  • पहले से बनाया गया structure, जानकारी आने से पहले विकल्प बंद करने वाली option cost और लागत को आगे खींचकर लाभ को देर से लाने वाली NPV cost — दोनों पैदा करता है
  • भले ही code generation की लागत लगभग 0 के करीब पहुँच जाए, YAGNI खत्म नहीं होता; बल्कि सस्ती generation अनुमान-आधारित framework बनाना और आसान कर सकती है
  • “ज़रूरत होने पर बनाओ” यह निष्कर्ष कोड लिखने की लागत की वजह से नहीं, बल्कि इसलिए है कि बिना इस्तेमाल किए हुए विकल्प और बिना खर्च किया हुआ पैसा अब भी मूल्य रखते हैं

YAGNI design को प्रतिबंधित नहीं करता

  • YAGNI, “You Aren’t Gonna Need It” का संक्षिप्त रूप है, और यह ऐसी दलील नहीं है कि जिसकी ज़रूरत नहीं है उसे कभी design ही मत करो
  • ज़रूरत हो तो उसे बनाया जा सकता है, लेकिन मुख्य बात timing है
  • इसकी शुरुआत उस किस्से से होती है जहाँ किसी project के दौरान यह सोचा गया कि “3 हफ्ते बाद simple implementation काफ़ी नहीं होगी, इसलिए अभी कुछ ज़्यादा complex बनाना चाहिए,” और जवाब बार-बार आया: “You aren’t going to need it”
  • यह सिद्धांत structure को बहुत जल्दी बनाने और बहुत देर से बनाने — दोनों को जोखिमपूर्ण मानता है

समस्या code लिखने की लागत नहीं, बल्कि अनुमान-आधारित structure है

  • आम व्याख्या यह है कि YAGNI एक बचत नियम है: “जिस कोड की अभी ज़रूरत नहीं, वह महँगा है, इसलिए मत लिखो”
  • लेकिन YAGNI का वास्तविक निशाना code production cost नहीं, बल्कि असली feature की ज़रूरत आने से पहले बना दिया गया speculative structure है
  • ऐसा structure, अलग-अलग समय और अलग-अलग कारणों से, दो तरह की लागत पैदा करता है

पहली लागत: विकल्प

  • अगर feature आने से पहले structure बना दिया जाए, तो उन requirements पर अनुमान के आधार पर commit करना पड़ता है जिन्हें आप अभी जानते ही नहीं हैं
  • जिन features के लिए पहले से तैयारी की जाती है, वे आम तौर पर बाद में सचमुच आने वाले features से अलग निकलते हैं, और नतीजतन दो बार लागत चुकानी पड़ती है
    • गलत shape वाले structure को bypass करने की लागत
    • उस structure को फिर से हटाने या तोड़ने की लागत
  • यह समस्या सिर्फ़ “prediction मुश्किल है” कह देने भर की नहीं है
  • अनुमान सही भी हो, तब भी बिना पहले commit किए बाद में सही structure बनाने का option खो देने की वजह से नुकसान बचा रहता है
  • इंतज़ार करना आलस नहीं, बल्कि विकल्प नाम की एक asset को अपने पास रखना है

दूसरी लागत: NPV

  • जैसे पैसे का time value होता है, वैसे ही features का भी time value होता है
  • अगर 3 महीने बाद ज़रूरी होने वाले किसी feature के लिए आप अभी structure बना देते हैं, तो लागत पहले आ जाती है और वह feature, जो वास्तव में पैसा कमाएगा, उसकी release देर से होती है
  • यह लागत तब भी होती है जब अनुमान सही निकले
  • बिल्कुल सही prediction भी लागत और लाभ के क्रम को नहीं बदल सकता; नुकसान उस अंतराल में पैदा होता है जहाँ लागत को लाभ से पहले रख दिया जाता है
  • option cost का मतलब है: “जानकारी आने से पहले commit मत करो,” और NPV cost का मतलब है: “ज़रूरत पड़ने से पहले भुगतान मत करो”
  • “बाद में ठीक करना बहुत महँगा पड़ेगा” जैसी आपत्ति आए, तब भी वह महँगा बदलाव खुद एक और prediction हो सकता है

code generation सस्ता हो जाए तब भी YAGNI बना रहता है

  • इन दोनों में से किसी भी लागत में code टाइप करने की लागत शामिल नहीं है
  • अगर code लिखने की लागत लगभग 0 के करीब चली जाए, तो YAGNI की यह बचत-केंद्रित व्याख्या — “कोड सस्ता हो गया है, इसलिए पहले से बना लो” — टिक नहीं पाती
  • लेकिन क्योंकि YAGNI कोई बचत नियम नहीं है, इसलिए सस्ती code generation YAGNI को निरर्थक नहीं बनाती
  • option cost मेहनत की मात्रा से नहीं, बल्कि future choices को बंद कर देने वाले commitment से पैदा होती है
  • NPV cost production price से नहीं, बल्कि cash flow की timing से पैदा होती है
  • मुफ्त generation YAGNI को कमज़ोर नहीं करती; उल्टा, यह अनुमान-आधारित framework बनाना और आसान कर सकती है
  • generated structure फिर भी वही दो लागतें पैदा करता है, और चूँकि उसे सीधे हाथ से नहीं लिखा गया, उसकी समझ शायद और कम हो सकती है
  • निष्कर्ष यह नहीं है कि “कोड महँगा है, इसलिए इंतज़ार करो,” बल्कि यह है कि विकल्प और पैसा, जब तक खर्च न किए जाएँ, अधिक मूल्यवान रहते हैं — इसलिए ज़रूरत पड़ने पर ही बनाओ

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की रायें

  • मुझे लगता है स्ट्रक्चर बदलने की लागत भी कम हुई है
    AI की वजह से स्ट्रक्चर बदलने से पहले व्यवहार को tests से मजबूत करने की लागत कम हुई है, और zero-downtime migration लागू करने की लागत भी घटी है
    Rust के चर्चा में आने की बड़ी वजहों में से एक, AI से पहले भी, यह थी कि application की internal structure बदलने की लागत कम थी, और अब तो यह और भी सच है
    सुरक्षित तरीके से स्ट्रक्चर न बदल पाने की opportunity cost बहुत बढ़ गई है, और आज हम code और product के बड़े हिस्सों को तेज़ी से और सुरक्षित रूप से बदल सकने की क्षमता को सबसे ऊपर रखकर optimize करते हैं

    • code और product के बड़े हिस्सों को तेज़ी से और सुरक्षित रूप से बदल सकने की क्षमता पहले से ही अच्छी चीज़ थी, और AI coding के आने से अलग भी उसकी value थी
      बस AI से पहले structural changes में कहीं ज़्यादा समय लगता था, इसलिए यह भी कहा जा सकता है कि जिस चीज़ के लिए हम अभी optimize कर रहे हैं, उसकी value उलटे कम हुई है
      अभी भी valuable है, लेकिन शायद पहले से थोड़ी कम
    • सहमत होना मुश्किल है
      नाज़ुक AI-generated tests बढ़ने से structure बदलने की लागत पहले से ज़्यादा हो गई है
      test suite को साफ़ करके समस्या के असली सार को verify कराना, और संयोगवश लिए गए design decisions को verify न कराना—यह काम AI अभी अच्छी तरह नहीं कर पाता
    • सही है
      लेकिन ऐसा न करके लगभग 75% पके हुए कमज़ोर test suite पा लेना भी बहुत आसान है
      बहुत से लोग “इंसान द्वारा लिखे कुछ साधारण और कमज़ोर tests” से “AI द्वारा लिखे बहुत सारे साधारण और कमज़ोर tests” तक जाने को objective improvement मानकर संतुष्ट हो जाते हैं
      tools को इस तरह इस्तेमाल करने से मैं पूरी तरह सहमत हूँ, लेकिन इसलिए यह मान लेना मुश्किल है कि बहुत जल्दी किसी गलत हवा-महल को खड़ा करने की चिंता नहीं करनी चाहिए
      refactoring को झेल सकने वाला perfect test contract design करना अभी भी काफ़ी कठिन है
    • यह मुझे open-closed principle की याद दिलाता है: “extension के लिए open, modification के लिए closed”
      पुरानी चीज़ फिर से नई बनकर लौट आई है
      DDD या clean architecture जैसे approaches की context efficiency से लेकर इन बातों तक, AI नए trade-offs नहीं बना रहा, बल्कि amplifier की तरह काम कर रहा है
      जो टीमें सही तरीके से करती हैं उनकी productivity बढ़ाता है, और जिन टीमों के design और architecture quality standards कम हैं उनका debt भी बढ़ाता है
    • ऐसा लगता है कि AI बाद में ठीक कर देगा, इस पर दांव लगाकर लोग और ज़्यादा फालतू छेड़छाड़ बढ़ा रहे हैं
      फायदा बस इतना है कि गहराई से सोचना नहीं पड़ता
      गहराई से सोचने में इतना ज़्यादा समय या मेहनत नहीं लगती, इसलिए वही AI इस्तेमाल करते हुए भी उतना सोचने वाले लोग, जिनकी कोशिशें फालतू छेड़छाड़ नहीं बनेंगी, उनसे आगे निकल जाएंगे

  • Kent Beck ने अभी न लिखे गए code की तुलना financial option से की है, जिसे किसी निश्चित price पर खरीदा जा सकता है
    लेकिन वह आखिरकार एक analogy ही है, और उसे बहुत दूर तक खींचें तो अजीब हो जाती है
    अगर आपने code की एक भी line नहीं लिखी, तो क्या आपके options infinite हैं? भले ही आपने अभी समय खर्च न किया हो, यह सही नहीं लगता
    यह code लिखने को अनिश्चितकाल तक टालते हुए planning stage में ही रहने का आधार भी बन सकता है, ताकि कुछ भी तय न करना पड़े
    फिर भी अगर यह analogy काम करती है, तो cost code पढ़ने में हो सकती है
    जो code लिखा ही नहीं गया, उसे पढ़ने की ज़रूरत नहीं; और अगर coding agent इस्तेमाल करें, तो वह अप्रासंगिक details से context को गंदा भी नहीं करता
    जो code अभी लिखा नहीं गया, उसे test करने की ज़रूरत भी नहीं, और जो tests अभी लिखे नहीं गए, उन्हें run करने का समय भी नहीं लगता
    इसलिए project को जितना संभव हो उतना छोटा रखना अच्छा है, और features टालने से codebase की growth को अधिकतम धीमा किया जा सकता है
    इसका मतलब यह भी है कि दूसरों का code चलाने से कई costs बच सकती हैं
    अगर standard API इस्तेमाल कर सकते हैं, तो implementation को detail में समझने या उसके tests चलाने की ज़रूरत नहीं, लेकिन dependency जोड़ने में risks होते हैं

    • Kent की “Tidy, First?” में software को दो तरीकों से value बनाते हुए देखा गया है: आज किया जाने वाला काम, और कल कुछ नया करवा सकने की संभावना
      न लिखा गया code value नहीं रखता
      आज लिखा गया code value बनाए, तो उसे आज की request या issue हल करनी चाहिए, या कल कुछ करना आसान बनाने की दिशा में झुका होना चाहिए
      hacky solution से technical debt लेना या YAGNI के खिलाफ चीज़ों पर समय बर्बाद करना value नहीं बनाता
      अहम बात न लिखा गया code नहीं, बल्कि आगे लिखा जाने वाला code और उसका purpose है
      आज के ticket·todo को हल करने और भविष्य में खुद के पैर पर कुल्हाड़ी न मारने के बीच सही trade-off करना होता है
      code लिखना एक commitment है; आज की value दिखती है, लेकिन कल की value ज़्यादातर estimate होती है
      फिर भी बाद में चुकाई जाने वाली cost हमेशा होती है, इसलिए क्या ज़रूरत पड़ेगी इसका अनुमान लगाकर cost को minimize करने की कोशिश की जाती है

  • मुझे लगता है कि AI युग की best practices पर पर्याप्त ज़ोर नहीं दिया जा रहा, लेकिन Kent से एक बात पूरी तरह छूट रही है
    किन features की ज़रूरत है, यह जल्दी पता लगाने में काफी value है
    speculative structure बनाना requirements को तय करवाने वाला forcing function हो सकता है, और कम से कम failure modes दिखने लगते हैं
    यह इंतज़ार करने से महंगा हो सकता है, इसलिए ज़्यादातर requirements के लिए ऐसा नहीं करना चाहिए, लेकिन कभी-कभी यह सबसे अच्छा विकल्प हो सकता है
    गलत चीज़ बनाने की cost अब बहुत कम हो गई है, इसलिए YAGNI के आसपास की calculation भी बदलती है
    फिर भी calculation अभी भी ज़रूरी है, और अब हर team को खुद समझना होगा कि उनके लिए यह कैसे बदली है

    • speculative structure को spike के रूप में बनाकर फेंक दें तो ठीक है
      अगर फेंकते नहीं, तो यह गंदा output बनाने वाला forcing function बन जाता है
    • मेरे हिसाब से ज़रूरी features पहले से ही requirements और उन requirements को पूरा करने वाले system design से आते हैं
      YAGNI की समस्या यह है कि current requirements में जो नहीं है, उसे बाद में requirements बदलेंगी यह मानकर बना दिया जाए
      यह current requirements और constraints को concrete बनाने से अलग है
      ऐसी चीज़ें मुख्य रूप से stakeholders·users·customers से बातचीत, resources, engineering constraints और capabilities से आती हैं
      prototype stakeholders से बात करने, project management model बनाने, या engineering research करने में valuable होता है
      उसके अलावा यह क्रम उल्टा कर देना है

  • चल रहे software को asset मानने वाला approach सही है
    हालांकि उसे चलाने और फिर से बनाने की लागत बहुत कम हो गई है
    जो लागत कम नहीं हुई, वह predictable results के लिए chain of trust तोड़ने की cost है
    चल रहे software के किसी खास version ने trust जमा किया होता है, और शुरू से फिर लिखने पर release के समय वह capital reset हो जाता है

  • एक समय के बाद मेरी सोच बदल गई
    ठोस चीज़ों को YAGNI के तहत टालकर, जहाँ तक संभव हो abstract version लिखने लगा
    UserStore बनाऊँ? वह सबसे सरल लगता है, लेकिन हो सकता है कि User जैसा कोई specific shape चाहिए ही न हो
    इसलिए ऐसा Store बनाता हूँ जिसमें store की जा सकने वाली कोई भी चीज़ रखी जा सके
    अगर यह परिचित न लगे तो यह overengineering और generics की भरमार जैसा दिखता है, लेकिन विडंबना यह है कि किसी भी concrete implementation से सबसे कम commitment करने का यही तरीका है

    • यह सचमुच overengineering और generics की भरमार जैसा ही दिखता है
      आपने न सिर्फ़ शायद गैर-ज़रूरी UserStore interface बनाया, बल्कि एक generalized Store abstraction भी बना डाला जिसकी पक्का ज़रूरत नहीं थी
      concrete implementation से commitment न करने के लिए आपने ऐसी चिपचिपी layers implement कर दीं जिनकी ज़रूरत नहीं है और आगे भी शायद नहीं होगी
      अगर abstraction असली ज़रूरत पर आधारित नहीं है, तो बाद में ज़रूरत पड़ने पर भी बहुत संभावना है कि वह गलत बनी होगी
      आखिरकार UserStore की ज़रूरत तो पड़ेगी, इसलिए पहले वही बनाना चाहिए था

  • “यह दावा कि prediction मुश्किल है, इस तरह का नहीं है कि कोई ज़्यादा तेज़ architect इसे avoid कर सकता था” — इससे मैं सहमत नहीं हूँ
    यह दावा तभी टिकता है जब आधारभूत मान्यता यह हो कि prediction मुश्किल है

    • “सटीक अनुमान लगाने पर भी, commit न करने से worse हो जाता है” — यह भी confusing है
      जिस feature की संभावना बहुत ज़्यादा है, उसके लिए पहले से आधार बना दें और सब कुछ फिट बैठ जाए, तो release जल्दी हो जाती है
      इसकी भी कोई guarantee नहीं कि team ज़रूर बड़ी होगी या headcount बना रहेगा, इसलिए deadline से ठीक पहले YAGNI पूरा करने के लिए हड़बड़ाने के बजाय संयम पर खुद को शाबाशी देना ज़्यादा खराब लगता है

  • हाल में मुझे YAGNI से भरे पड़े codebase से functional रूप से बाहर निकलना पड़ा, और agents होने के बावजूद वह बहुत बड़ा काम था
    distributed system में आप कैसे जानेंगे कि कौन-सी चीज़ सच में use हो रही है? कुछ चीज़ें मैंने miss कीं, कुछ agent ने miss कीं, और पूरी चीज़ ज़रूरत से कहीं ज़्यादा लंबी चली
    यह सिर्फ़ 1:1 porting भी नहीं थी; हमने इसे simplify करने का मौका माना था, इसलिए पुराने system के काम करने के तरीके को पूरी तरह समझना पड़ा
    जो चीज़ें असल में बिल्कुल use नहीं हो रही थीं, अगर उन्हें ऐसा identify नहीं कर पाए, तो वे भी समझने के दायरे में शामिल हो गईं

  • आखिर बात problem को explore करने और solution implement करने तक आती है, ऐसा मुझे लगता है
    गलत problem हल करने की हमेशा cost होती है, और जिसकी ज़रूरत ही नहीं है उसके लिए खराब solution implement करने की भी cost होती है
    software development कभी-कभी explore करने वाली strategies और problem set के बारे में सोचने के बजाय सरल trial and error में बह सकता है
    कुछ मामलों में, ज़रूरत से ज़्यादा किसी खास दिशा में problem को गहराई से explore करना long term में मददगार होता है, लेकिन बिना उद्देश्य के solution implement करना कभी अच्छा नहीं होता
    मुझे लगता है कि Kent Beck असल में उस रवैये की आलोचना कर रहे हैं जिसमें भविष्य में शायद ज़रूरत पड़ जाए, इसलिए “क्या पता” सोचकर कुछ implement कर दिया जाता है

  • कहा गया था कि “feature आने से पहले structure बनाना guess पर commit करना है”, लेकिन मेरे हिसाब से दोनों तरफ़ guess होता है
    feature आने की संभावना ज़्यादा हो सकती है, लेकिन निश्चित नहीं
    अभी structure न बनाएं तो refactoring cost है, और बहुत जल्दी बना दिया लेकिन feature न आया तो effort waste है
    उन संभावनाओं के बीच cost, probability और trade-off क्या हैं? बेशक यह context पर निर्भर करता है
    पूरा YAGNI जानबूझकर किया गया बड़ा generalization है
    आखिरकार बात circumstances पर निर्भर है
    किसी भी तरफ़ अक्सर guesses और हाथ हिलाकर दी गई explanations भरी होती हैं, और यह भरोसेमंद work estimation जैसी ही समस्या है
    अनिश्चित दुनिया को अच्छी तरह सहन न कर पाने वाले कुछ developers हर चीज़ के लिए black-and-white rules खोजने लगते हैं

  • Kent Beck के लेखों में मैंने ऐसा कुछ नहीं देखा जो chip company के लिए उपयोगी हो
    chip company में बहुत से लोगों को लंबे समय तक काम करना पड़ता है, customers तैयार होने तक कुछ भी नहीं देख सकते, और पैसा कमाने के लिए millions की संख्या में बेचना पड़ता है

    • क्या वे software बनाने वाले और software development के बारे में लिखने वाले व्यक्ति नहीं हैं?
      hardware में कड़े constraints होते हैं
      software का आविष्कार भी मूल रूप से ऐसे constraints से बचने के लिए ही हुआ था
    • customers तैयार होने से पहले बिल्कुल नहीं देख सकते, यह हमेशा सही नहीं है
      यह सही है कि कई chip companies work in progress साझा नहीं करतीं, लेकिन simulations, prototypes और engineering samples साझा करना संभव है और वास्तव में होता भी है
      बेशक आम तौर पर customer बड़ा होना चाहिए
      जिन industries में change cost अपेक्षाकृत कम है, उनकी insights बड़ी change cost वाली industries पर आसानी से लागू नहीं होतीं, और उल्टा भी अक्सर ऐसा ही होता है
    • दिलचस्प है
      chip companies ऐसे projects की planning कैसे करती हैं? Agile, waterfall, या software industry से अलग कोई framework इस्तेमाल करती हैं?