- 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 टिप्पणियां
लगता है कि Agile को गलत समझने वाले मैनेजरों की समस्या को Agile की समस्या समझने की गलती की जा रही है।
लगता है कि समय के रुझान के साथ low-level ज्ञान सीखने से ROI नहीं निकलता, इसलिए लोग सिर्फ high-level ज्ञान सीखने तक ही सीमित रह जाते हैं
आख़िर बेकार में Agile को ही क्यों निशाना बनाया जा रहा है ...
north-south और east-west कॉन्सेप्ट्स को मिलाकर बात की गई है, इसलिए बात थोड़ी कन्फ्यूज़िंग लगती है.
दूसरी टीम क्या कर रही है यह पता न होना, मुझे लगता है कि Agile से ज़्यादा cross-functional ऑर्गनाइज़ेशनल स्ट्रक्चर की समस्या है.
low level के बारे में अच्छी समझ न होना—अगर सामग्री देखें तो बात कुछ ऐसी है कि "ऐसा होने पर low level की भी अच्छी समझ नहीं रहती".
दूसरी टीम क्या कर रही है यह न पता होना थोड़ा-बहुत Agile से जुड़ा मान भी लें, तब भी low level न जानने का Agile से क्या संबंध है, यह समझ नहीं आता lol
अगर सख्ती से देखें, तो open source के व्यापक रूप से फैलने के बाद अब सब कुछ खुद बनाने की ज़रूरत नहीं रही, इसलिए wheel को फिर से invent नहीं किया जाता, और low level वाली चीज़ें बस बाहर से लेकर इस्तेमाल कर ली जाती हैं—इसलिए लोग पढ़ाई नहीं करते—यह बात शायद ज़्यादा करीब लगती है.
अगर उस बात को समझने की कोशिश करें, तो इतना तो कहा जा सकता है कि Agile की वजह से लोग सिर्फ़ जल्दी बनाने पर ध्यान देते हैं, इसलिए low level नहीं पढ़ते; लेकिन मुझे लगता है कि "ज़रूरत नहीं है, इसलिए नहीं करते" कहना ज़्यादा सही होगा.
मुझे लगता है कि Agile की वजह से समस्याओं को व्यापक नज़रिए से देखने और लंबे समय तक टिकाऊ बनाने वाले विकल्पों की अनदेखी बढ़ रही है, और सॉफ्टवेयर के नज़रिए से भी यह केवल सामने की समस्या हल करने पर ही ध्यान केंद्रित करवाता जा रहा है।
बिना सोचे-समझे बस किसी तरह चीज़ों को चलने लायक बना देना Agile होना नहीं है, लेकिन ऐसा लगता है कि बहुत ज़्यादा गति-केंद्रित विकल्प चुनने की प्रवृत्ति पैदा होती है, और यह गहरी समझ हासिल करना मुश्किल बनाने वाला एक कारण हो सकता है।
मुझे समझ नहीं आता कि engineering organization में decision-making authority न होने की समस्या का कारण Agile में क्यों ढूंढने की कोशिश की जा रही है।
दूसरी टीम क्या कर रही है, यह न जानने वाली स्थिति का Agile से क्या संबंध है... ;;;
वैसे,
Window Snyderनाम काफ़ी अनोखा है...लगता है कि मैं मूल वीडियो देखना चाहता हूँ, लेकिन अभी वह उपलब्ध नहीं है। शायद कुछ समय बाद वह आधिकारिक YouTube पर अपलोड हो जाए।
https://www.youtube.com/@BlackHatOfficialYT/
Hacker News राय
समस्या की जड़ आधुनिक corporate structure है
Agile के अच्छे ideas सामान्य software engineering में समा गए
Agile, Scrum और OKR को लेकर असंतोष
backlog refinement meeting का अनुभव
Agile की समस्याओं पर एक theory
software quality में गिरावट
engineers को code के कुछ हिस्सों का "ownership" मिलना चाहिए
daily stand-up meetings से बचने का अनुभव
बड़े संगठनों की समस्या
software development के "जादू" को वापस लाने की राय
> एक आधुनिक management theory है कि ज़िम्मेदारी और decision-making को corporate hierarchy के साथ ऊपर की ओर जाना चाहिए।
क्या यह bureaucratic organization की विशेषता नहीं है?