17 पॉइंट द्वारा GN⁺ 2024-08-12 | 11 टिप्पणियां | WhatsApp पर शेयर करें
  • Black Hat कॉन्फ्रेंस में Signal के संस्थापक Moxie Marlinspike ने दावा किया कि Agile development की वजह से पिछले 20 वर्षों में software innovation गायब होती जा रही है
  • उन्होंने कहा कि developers "black-box abstraction layers" में फँस गए हैं और innovation के लिए ज़रूरी आज़ादी खो चुके हैं
  • "Engineering organization को manage करने वाला लगभग हर व्यक्ति किसी न किसी ऐसी management philosophy का पालन करता है जो या तो Agile की sub-concept है, उससे निकली है, उसके दायरे में आती है, या किसी न किसी तरह उससे जुड़ी हुई है"
    • उनका कहना है कि जहां developers को engineering expertise और existing technologies में नए features देखने की vision को जोड़ते हुए bottom-up तरीके से आगे बढ़ना चाहिए,
      वहीं Agile teams अलग-अलग silo में बँट जाती हैं, अलग-अलग काम करती हैं, और यह समझ ही नहीं पातीं कि दूसरी teams क्या कर रही हैं
  • समापन सत्र में Thistle Technologies की संस्थापक और CEO Window Snyder ने जोड़ा कि ऐसे black-box teams में अक्सर इस बात की visibility भी कम होती है कि उनका अपना product कैसे काम करता है
    • Snyder का यह भी तर्क था कि programming सीखने वाले students low-level languages या machine code के साथ interact करना नहीं सीखते, बल्कि केवल वे high-level languages सीखते हैं जो app development को आसान बनाती हैं, इसलिए engineers के पास यह समझने के लिए ज़रूरी context नहीं होता कि puzzle के टुकड़े मिलकर बड़े पूरे ढाँचे में कैसे फिट होते हैं

सुरक्षा शोधकर्ताओं के पास innovation की कुंजी है

  • Marlinspike ने यह भी कहा कि पिछले कई दशकों में software engineering को और तेज़, अधिक flexible और आगे बढ़ाने के लिए abstract किया जाता रहा है, जबकि security researchers abstractions के पार देखने की कोशिश करते रहे हैं
    • "Security उस प्रक्रिया का नाम है जिसमें abstract चीज़ों के अंदर झाँककर यह समझा जाता है कि वे वास्तव में कैसे काम करती हैं, उनके नीचे क्या है, और कभी-कभी उन्हें बनाने वाले लोगों से भी बेहतर समझा जाता है"
  • इसलिए उनका दावा है कि security researchers के पास नई innovation को आगे बढ़ाने की कुंजी है
  • उन्होंने यह उपमा भी दी कि software को समझना मानो magic को समझने जैसा है, और security experts वे "लोग हैं जो library में बैठकर magic का अध्ययन करते हैं"

GN⁺ की राय

  • यह Agile की बुनियादी समस्याओं को तीखे ढंग से सामने लाने वाला Marlinspike का insightful बयान था
  • इस बात से सहमति है कि abstraction और तेज़ development speed पर अत्यधिक ज़ोर देने से developers धीरे-धीरे बुनियादी concepts से दूर होते जा रहे हैं
  • security researchers की भूमिका पर दिया गया ज़ोर प्रभावशाली लगा। Security abstraction के पीछे छिपी वास्तविकता को खंगालने का काम है, इसलिए यह innovation की driving force बन सकती है
  • एक तरह से यह संदेश भी है कि software engineers को अधिक गहरी समझ की तलाश करनी चाहिए
  • Agile के फ़ायदे भी स्पष्ट हैं, इसलिए balanced approach की ज़रूरत है। Agile की agility और flexibility को बनाए रखते हुए fundamentals को मज़बूत करने के तरीकों पर विचार होना चाहिए
  • इसके लिए development education curriculum से ही सुधार की ज़रूरत है। high-level languages के साथ-साथ low-level languages, computer architecture जैसे foundational subjects की शिक्षा भी मज़बूत की जानी चाहिए

11 टिप्पणियां

 
jeokrang 2024-08-20

लगता है कि Agile को गलत समझने वाले मैनेजरों की समस्या को Agile की समस्या समझने की गलती की जा रही है।

 
yangeok 2024-08-20

लगता है कि समय के रुझान के साथ low-level ज्ञान सीखने से ROI नहीं निकलता, इसलिए लोग सिर्फ high-level ज्ञान सीखने तक ही सीमित रह जाते हैं

 
andrewchaa 2024-08-14

आख़िर बेकार में Agile को ही क्यों निशाना बनाया जा रहा है ...

 
lordang 2024-08-12

north-south और east-west कॉन्सेप्ट्स को मिलाकर बात की गई है, इसलिए बात थोड़ी कन्फ्यूज़िंग लगती है.
दूसरी टीम क्या कर रही है यह पता न होना, मुझे लगता है कि Agile से ज़्यादा cross-functional ऑर्गनाइज़ेशनल स्ट्रक्चर की समस्या है.

low level के बारे में अच्छी समझ न होना—अगर सामग्री देखें तो बात कुछ ऐसी है कि "ऐसा होने पर low level की भी अच्छी समझ नहीं रहती".

दूसरी टीम क्या कर रही है यह न पता होना थोड़ा-बहुत Agile से जुड़ा मान भी लें, तब भी low level न जानने का Agile से क्या संबंध है, यह समझ नहीं आता lol

 
lordang 2024-08-12

अगर सख्ती से देखें, तो open source के व्यापक रूप से फैलने के बाद अब सब कुछ खुद बनाने की ज़रूरत नहीं रही, इसलिए wheel को फिर से invent नहीं किया जाता, और low level वाली चीज़ें बस बाहर से लेकर इस्तेमाल कर ली जाती हैं—इसलिए लोग पढ़ाई नहीं करते—यह बात शायद ज़्यादा करीब लगती है.

अगर उस बात को समझने की कोशिश करें, तो इतना तो कहा जा सकता है कि Agile की वजह से लोग सिर्फ़ जल्दी बनाने पर ध्यान देते हैं, इसलिए low level नहीं पढ़ते; लेकिन मुझे लगता है कि "ज़रूरत नहीं है, इसलिए नहीं करते" कहना ज़्यादा सही होगा.

 
bbulbum 2024-08-12

मुझे लगता है कि Agile की वजह से समस्याओं को व्यापक नज़रिए से देखने और लंबे समय तक टिकाऊ बनाने वाले विकल्पों की अनदेखी बढ़ रही है, और सॉफ्टवेयर के नज़रिए से भी यह केवल सामने की समस्या हल करने पर ही ध्यान केंद्रित करवाता जा रहा है।
बिना सोचे-समझे बस किसी तरह चीज़ों को चलने लायक बना देना Agile होना नहीं है, लेकिन ऐसा लगता है कि बहुत ज़्यादा गति-केंद्रित विकल्प चुनने की प्रवृत्ति पैदा होती है, और यह गहरी समझ हासिल करना मुश्किल बनाने वाला एक कारण हो सकता है।

 
savvykang 2024-08-12

मुझे समझ नहीं आता कि engineering organization में decision-making authority न होने की समस्या का कारण Agile में क्यों ढूंढने की कोशिश की जा रही है।

 
galadbran 2024-08-12

दूसरी टीम क्या कर रही है, यह न जानने वाली स्थिति का Agile से क्या संबंध है... ;;;

वैसे, Window Snyder नाम काफ़ी अनोखा है...

 
xguru 2024-08-12

लगता है कि मैं मूल वीडियो देखना चाहता हूँ, लेकिन अभी वह उपलब्ध नहीं है। शायद कुछ समय बाद वह आधिकारिक YouTube पर अपलोड हो जाए।
https://www.youtube.com/@BlackHatOfficialYT/

 
GN⁺ 2024-08-12
Hacker News राय
  • समस्या की जड़ आधुनिक corporate structure है

    • एक आधुनिक management theory है कि जवाबदेही और decision-making को corporate hierarchy के साथ ऊपर जाना चाहिए
    • निचले स्तर के कर्मचारियों को product के बारे में सबसे कम जानने वाला माना जाता है
    • लेकिन वास्तव में frontline कर्मचारी ही सबसे ज़्यादा जानकारी रखते हैं
    • software engineering को assembly line process बना देने से innovation रुक जाता है
    • बराबरी वाला management hierarchy ही जवाब नहीं है, लेकिन frontline कर्मचारियों को powerless न बनाने का तरीका चाहिए
    • <i>Reinventing Organisations</i> किताब innovative corporate structures के बारे में बताती है
  • Agile के अच्छे ideas सामान्य software engineering में समा गए

    • Agile programmer को अक्सर सख्त stand-up meetings, Kanban board आदि का पालन करने वाला माना जाता है
    • ऐसा नहीं लगता कि Agile ने knowledge fragmentation और software engineering की skill degradation पैदा की है
    • यह mass production की प्रवृत्ति से पैदा हुई समस्या है
    • car companies या furniture factories में भी ऐसा ही दिखता है
  • Agile, Scrum और OKR को लेकर असंतोष

    • ये सभी निचले स्तर के कर्मचारियों को freedom और responsibility देने का वादा करते हैं, लेकिन व्यवहार में centralization हो जाता है
    • OKR को उल्टा लागू करके देखना चाहूँगा
    • हर कर्मचारी को अपने क्षेत्र में key results परिभाषित करने चाहिए, और manager को उसके आधार पर team की direction तय करनी चाहिए
    • top-down नहीं, bottom-up approach चाहिए
    • अच्छी hiring, अच्छी training और कर्मचारियों पर trust होना चाहिए
  • backlog refinement meeting का अनुभव

    • अपरिचित code में bug fix का estimation करना था
    • estimate करना मुश्किल था, इसलिए बस कोई संख्या बोल दी
    • Agile तीन जगहों पर लगभग इसी तरह चलाया गया
  • Agile की समस्याओं पर एक theory

    • काम को छोटे हिस्सों में बाँटना उपयोगी है, लेकिन programming में creativity चाहिए
    • काम को बाँटने की प्रक्रिया में बहुत-सी जानकारी खो जाती है
    • developer को creative solutions ढूँढने होते हैं, लेकिन उसे ज़रूरी जानकारी नहीं मिलती
    • ज़्यादा experienced developers या बेहतर design diagrams और documentation की ज़रूरत है
  • software quality में गिरावट

    • पिछले कई दशकों में software बदतर हुआ है
    • मशीनें ज़्यादा शक्तिशाली हैं, लेकिन responsiveness कम है
    • इसका संबंध Agile के उभार से हो सकता है
  • engineers को code के कुछ हिस्सों का "ownership" मिलना चाहिए

    • वही समय था जब team का software सबसे बेहतरीन था
  • daily stand-up meetings से बचने का अनुभव

    • लगातार retrospectives और काम को बाँटना inefficient था
    • इसका फायदा सिर्फ non-technical managers को था
  • बड़े संगठनों की समस्या

    • developers अब नेतृत्व नहीं करते
    • vision, product, UX और project management ऊपर से तय होते हैं
    • developers cloud technologies का इस्तेमाल करके काम करते हैं
    • वे पूरी तस्वीर समझ नहीं पाते या महत्वपूर्ण सुझाव नहीं दे पाते
  • software development के "जादू" को वापस लाने की राय

    • लगता है कि यह राय किसी ऐसे व्यक्ति की है जो 20 साल से ज़्यादा समय से industry में है
    • युवा programmers के साथ समय बिताने पर लगता है कि जादू अभी भी मौजूद है
    • 20 साल पहले भी ऐसी ही शिकायतें थीं, लेकिन तब भी लोग मज़े से काम करते थे
 
savvykang 2024-08-13

> एक आधुनिक management theory है कि ज़िम्मेदारी और decision-making को corporate hierarchy के साथ ऊपर की ओर जाना चाहिए।

क्या यह bureaucratic organization की विशेषता नहीं है?