हम software को बर्बाद कर रहे हैं

 (antirez.com)
31 पॉइंट द्वारा GN⁺ 2025-02-09 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • हम features जोड़ते समय या किसी खास हिस्से को optimize करते समय complexity को अब ध्यान में नहीं रखकर software को बर्बाद कर रहे हैं
  • हम जटिल build systems के साथ software को बर्बाद कर रहे हैं
  • हम बेहूदी dependency chains के साथ हर चीज़ को फुलाकर और नाज़ुक बनाकर software को बर्बाद कर रहे हैं
  • हम नए programmers से "Don’t reinvent the wheel!" कहकर software को बर्बाद कर रहे हैं। लेकिन wheel को फिर से बनाना यह सीखने का तरीका है कि चीज़ें कैसे काम करती हैं, और एक नए, अलग wheel को बनाने का पहला कदम भी है
  • हम API backward compatibility को अब ध्यान में नहीं रखकर software को बर्बाद कर रहे हैं
  • हम पहले से काम कर रही चीज़ों को rewrite करने के लिए दबाव डालकर software को बर्बाद कर रहे हैं
  • हम हर नई language, paradigm, framework आते ही उस पर कूद पड़कर software को बर्बाद कर रहे हैं
  • हम मौजूदा जटिल libraries को संभालने की मुश्किल को, उसे खुद implement करने की तुलना में, हमेशा कम आँककर software को बर्बाद कर रहे हैं
  • हम यह मानकर software को बर्बाद कर रहे हैं कि XYZ का de facto standard हमारी खास ज़रूरत के मुताबिक खुद implement की जा सकने वाली चीज़ से हमेशा बेहतर होता है
  • हम यह दावा करके software को बर्बाद कर रहे हैं कि code comments बेकार हैं
  • हम software को सिर्फ़ एक शुद्ध engineering discipline समझने की भूल करके software को बर्बाद कर रहे हैं
  • हम ऐसे systems बनाकर software को बर्बाद कर रहे हैं जिन्हें अब छोटा नहीं किया जा सकता: किसी भी system में साधारण चीज़ें साधारण तरीके से हासिल की जानी चाहिए
  • हम जितनी जल्दी हो सके code निकालने की कोशिश करते हुए, जितना अच्छा design किया हुआ code हो सके उतना बनाने की कोशिश न करके software को बर्बाद कर रहे हैं
  • हम software को बर्बाद कर रहे हैं, और जो बचेगा वह अब hacking की खुशी नहीं देगा

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

7 टिप्पणियां

 
dohyun682 2025-02-11

पहिए को दोबारा बनाना <-> जो पहले से लिखा जा रहा है उसे फिर से बनाना

क्या ये दोनों एक-दूसरे के बिल्कुल विपरीत अवधारणाएँ नहीं हैं?
 
roxie 2025-02-10

कमेंट्स का बूम आने वाला है
 
tujuc 2025-02-10

बिलकुल relatable है हाहाहा जब भी नए जूनियर्स आते हैं... मैं सोचता रहता हूँ कि उन्हें कैसे सिखाऊँ। लगता है, यह एक अच्छा तरीका हो सकता है..
 
ilikeall 2025-02-10

कृपया मारना बंद करें, प्लीज़ प्लीज़
 
bus710 2025-02-10

....मैं बस चुप ही रहूंगा...
 
laeyoung 2025-02-09

ऐसा लगता है कि इसमें Han Feizi द्वारा कही गई "देश के पतन के 10 संकेत" वाली बातों से काफ़ी समानताएँ हैं।
 
GN⁺ 2025-02-09
Hacker News राय

  • Jonathan Blow की एक talk याद दिलाती है। software को manage न किया जाए तो वह बाकी हर चीज़ की तरह degrade होता है

    • software technology ऊपर से आगे बढ़ती हुई दिखती है, लेकिन असल में decline में है
    • hardware improvements और machine learning progress advancement का illusion देते हैं, लेकिन software की बुनियादी robustness और reliability खराब हो रही है
    • modern software development बेवजह इतना complex हो गया है कि simple काम भी मुश्किल हो जाते हैं
    • यह complexity programmers की productivity घटाती है और पीढ़ियों के बीच knowledge transfer में बाधा डालती है
    • society बहुत सारे bugs वाले और unreliable software को normal मानने लगी है
    • operating systems से लेकर development tools तक हर स्तर पर software systems को simplify नहीं किया गया, तो civilization ऐतिहासिक collapse जैसी technical regression के खतरे का सामना कर सकती है

  • Dieter Rams के "अच्छे design के 10 सिद्धांत" याद आते हैं

    • अच्छा design innovative होता है
    • अच्छा design product को useful बनाता है
    • अच्छा design aesthetic होता है
    • अच्छा design product को समझना आसान बनाता है
    • अच्छा design unobtrusive होता है
    • अच्छा design honest होता है
    • अच्छा design लंबे समय तक टिकता है
    • अच्छा design आखिरी detail तक thorough होता है
    • अच्छा design environment-friendly होता है
    • अच्छा design जितना संभव हो उतना कम design होता है

  • 2000s में company में काम करने का अनुभव साझा किया गया

    • दर्जनों computers से काम किए जाते थे, server room बनाया गया था, और 3TB data store करने के लिए SAN बनाया गया था
    • in-house developed VB6 job scheduler से Object Rexx scripts चलाने वाले computers के बीच jobs coordinate की जाती थीं
    • internal load balancer, web server, mail server, FTP server से files भेजी-ली जाती थीं और अपना software इस्तेमाल होता था
    • अब yaml files और cloud services के जरिए एक हफ्ते के भीतर पूरा setup फिर से बनाया जा सकता है
    • server architecture "abstract" हो गया है
    • backward compatibility की आलोचना की गई, इसे Windows की समस्याओं में से एक बताया गया
    • Apple ने backward compatibility तोड़ी, 5 processors पर migration किया, और ARM chips पर 32-bit code compatibility हटा दी

  • कई परस्पर विरोधी राय हैं

    • backward compatibility बनाए रखते हुए complexity से बचना चाहिए
    • विशाल dependency trees से बचना चाहिए और खुद wheel reinvent करना चाहिए
    • सभी requirements को पूरा करने का एकमात्र तरीका है कि हर कोई code न लिखे
    • दिन में एक बार ऐसा होने की कामना होती है, लेकिन इस पर गर्व नहीं है

  • पहली job का अनुभव साझा किया गया

    • software C में लिखा जाता था, और commercial software realistically लिखने के लिए वही एकमात्र language थी
    • build सिर्फ एक व्यक्ति कर सकता था, commercial build tool इस्तेमाल होता था, और वही उसे इस्तेमाल कर सकता था
    • build में कई घंटे लगते थे
    • हमें लगता था कि हम अच्छा कर रहे हैं

  • software को बर्बाद करने के कारणों पर राय

    • हम software को इसलिए बर्बाद करते हैं क्योंकि हम हमेशा सोचते हैं कि XYZ का de facto standard हमारी customized चीज़ से बेहतर है
    • generic approach कई समस्याओं के लिए सतही समाधान की ओर आसानी से मुड़ जाती है
    • engineers इस approach को पसंद करते हैं, खासकर क्योंकि वे अक्सर jobs बदलते रहते हैं, इसलिए उनके पास कुछ ready-made चीज़ें होती हैं
    • लेकिन customized solutions अक्सर generic ones की तुलना में बहुत बेहतर perform करते हैं

  • हर कथन एक trade-off है

    • हर मामले में कुछ छोड़कर कुछ और हासिल किया जाता है
    • कभी-कभी wheel reinvent न करना उचित होता है
    • कभी-कभी सीखने के लिए wheel reinvent करना पड़ता है
    • कुल मिलाकर हम destruction से ज्यादा creation कर रहे हैं
    • नकारात्मक stance लेने की ज़रूरत महसूस नहीं होती

  • antirez का सम्मान है, लेकिन लगता है कि यह post ऐसे short statements से भरी है जो सुनने में अच्छे लगते हैं, पर discussion में टिक नहीं पाएंगे

    • उदाहरण: beginners को wheel reinvent नहीं करना चाहिए
    • उन्हें दिए गए context में उपलब्ध tools का इस्तेमाल करना चाहिए
    • अगर वे experiment करना चाहते हैं, तो उन्हें अपना compiler लिखना चाहिए
    • लेकिन उसे production में इस्तेमाल नहीं करना चाहिए
    • reverse API compatibility ज्यादातर मामलों में business decision होता है
    • हर वाक्य की शुरुआत "हम software को बर्बाद कर रहे हैं" से करना मददगार नहीं है
    • यह हकीकत से कहीं ज्यादा gloomy सुनाई देता है

  • complexity/dependency graph पर राय

    • किसी भी random application का complexity/dependency graph बिल्कुल पागलपन भरा होता है
    • इसमें firmware और OS शामिल नहीं हैं, लेकिन काफी करीब है
    • transitive dependency problem को हल करना चाहिए
    • OS (Win32 API, Linux syscalls) को C में लिखी हर चीज़ की एकमात्र hard dependency माना गया
    • Java/Python पर switch करने पर इस layer को control नहीं किया जा सकता
    • हर library पर depend करने की बजाय किसी खास स्थिति के लिए कुछ सौ lines का code लिखना ज़रूरी है
    • maintenance burden बढ़ता है, लेकिन dependencies को भी maintenance चाहिए
    • उनमें गलत API हो सकती है, compatibility को random तरीके से तोड़ सकती हैं, abandon हो सकती हैं, या malware बन सकती हैं
    • useful projects के लिए personal maximum line count 5-10KLOC Java/JS/Python है
    • इसे कुछ घंटों में review किया जा सकता है और कई साल बाद भी आसानी से modify किया जा सकता है

  • software को बर्बाद करने वाले तत्व

    • Leetcode interviews, resume-driven development, frequent job switching, growth investment scams, metrics game, promotion chasing, sprint theater, organizational chart के हर स्तर पर bluffing, industry apathy