आपकी इंजीनियरिंग टीम धीमी होने की असली वजह लोग नहीं, बल्कि codebase है

 (piechowski.io)
40 पॉइंट द्वारा GN⁺ 26 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Codebase Drag codebase की वह स्थिति है जिसमें हर काम ज़रूरत से ज़्यादा समय लेता है, लेकिन यह dashboard या sprint report में दिखता नहीं, इसलिए leadership इसे बार-बार 'लोगों की समस्या' समझने की गलती करती है
  • कई वर्षों के codebase audit के नतीजों में वही 5 संकेत बार-बार दिखाई दिए, और इन्हें 0~2 अंकों में मापने वाला diagnostic rubric, 'Codebase Drag Audit', प्रस्तुत किया गया
  • estimate को बढ़ा-चढ़ाकर बताना, deploy का डर, "उस file को मत छूना", coverage का झूठ, और first commit तक लगने वाला समय — ये 5ों संकेत codebase quality की समस्या से पैदा होते हैं, न कि लोगों की क्षमता की कमी से
  • जितने अनुभवी engineer होते हैं, वे codebase के जोखिम को उतना बेहतर समझते हैं और इसलिए अधिक सावधानी से चलते हैं, जिससे उल्टा उनके और धीमे दिखने का विरोधाभास पैदा होता है; इसे talent problem समझने पर सिर्फ process बढ़ाने का उल्टा असर होता है
  • 4 या उससे अधिक अंक होने पर codebase में सीधे निवेश की ज़रूरत है, और 7 या उससे अधिक अंक तुरंत संरचनात्मक हस्तक्षेप की मांग करते हैं

Codebase Drag क्या है

  • Codebase Drag वह स्थिति है जिसमें codebase हर काम को ज़रूरत से ज़्यादा लंबा बना देता है, और यह sprint report या dashboard में दिखाई नहीं देता
    • उदाहरण: client team ने admin panel में CSV export feature जोड़ने के लिए 2 engineers के 1 हफ्ते खर्च किए — असली काम सिर्फ 1 दिन का था, बाकी समय मौजूदा code को सुरक्षित रूप से बदलने के लिए उसे समझने में लगा
  • जब टीम की गति बार-बार गिरती है, तो leadership इसे talent problem मानकर संगठन में फेरबदल, process जोड़ना, या लोगों को बदलना जैसे कदम उठाती है, लेकिन अगली टीम भी उसी दीवार से टकराती है
  • समस्या की जड़ bug, missing feature, या आम तौर पर कही जाने वाली technical debt भी नहीं, बल्कि codebase खुद है

Codebase Drag के 5 संकेत

1. माफ़ीनुमा estimate (Apology Estimate)

  • यह वह स्थिति है जब engineer किसी ऐसे feature के लिए, जिसे वास्तव में 3 दिन लगने चाहिए, 2 हफ्तों का estimate देता है, और leadership इसे timeline को बढ़ा-चढ़ाकर बताना समझती है
  • असली वजह होती है billing module में बदलाव करने पर notification system तक असर पहुँचाने वाला modules के बीच coupling, और ऐसा ढांचा जिसमें बदलाव का असर कहाँ तक जाएगा, यह पहले से समझना मुश्किल हो
    • hidden default scope या गहराई से nested callback की वजह से बदलाव के प्रभाव-क्षेत्र (blast radius) का अनुमान code का आधा हिस्सा पढ़े बिना लगाना संभव नहीं
  • अगर estimate लगातार अपेक्षा से 2~3 गुना समय ले रहे हैं, तो यह estimating की नहीं बल्कि codebase cost की समस्या है

2. deploy का डर (Deploy Fear)

  • टीम Friday को deploy करने से बचती है, या deploy को जोड़-जोड़कर बड़े batch में कम बार release करती है
  • एक client team ने Wednesday के बाद deploy न करने का अनौपचारिक नियम बना रखा था — 3 Thursday deploy के बाद weekend outage होने के कारण यह आदत बनी
    • इसकी वजह थी rollback strategy की कमी, भरोसेमंद test का न होना, और 45 मिनट लंबी deploy pipeline
  • DORA के हिसाब से elite teams का change failure rate 5% से कम होता है और वे ज़रूरत पड़ने पर तुरंत deploy कर सकती हैं, लेकिन यह टीम हफ्ते में 1 बार deploy करके भी घबराई रहती थी

3. 'उस file को मत छूना' (Don't Touch That File)

  • लगभग हर जगह पहले 2 दिनों के भीतर "उस file को मत छूना" जैसी बात सुनने को मिलती है
    • जैसे 30 before_action वाला billing controller, या git log में ऊपर दिखने के बावजूद संरचनात्मक रूप से वर्षों से न छुआ गया model
  • git log --oneline --since="2 years ago" चलाने पर सबसे ज़्यादा बदली गई file वही निकलती है जिसके बारे में चेतावनी दी गई थी — अगर सिर्फ छोटे patch बार-बार किए गए हों और कोई structural work न हुआ हो, तो इसका मतलब है कि लक्षणों का इलाज हो रहा है, बीमारी का नहीं
  • असली लागत यह है कि जिस module में feature होना चाहिए, वह कहीं और implement किया जाने लगता है, और नए joiners पहले हफ्ते में ही उस file से बचना सीख जाते हैं — codebase dead zone के इर्द-गिर्द विकृत तरीके से बढ़ने लगता है

4. coverage का झूठ (Coverage Lie)

  • 80% test coverage का आंकड़ा देखने में स्वस्थ लगता है, लेकिन असल में serializer, helper, और utility tests जैसे शायद ही कभी टूटने वाले tests इस संख्या को संभाले हुए होते हैं, जबकि पैसे संभालने वाले 3 core models पर एक भी test नहीं होता
  • test suite regression पकड़ने के बजाय metric को अच्छा दिखाने के लिए मौजूद रहता है — tests pass होते हैं, फिर भी production टूट जाता है
  • CI time 40 मिनट होने पर developers local tests चलाना बंद कर देते हैं → coverage का आंकड़ा दो तरह से झूठ बोलता है: वह महत्वपूर्ण हिस्सों को cover नहीं करता, और जो tests मौजूद हैं वे भी चलाए नहीं जाते
  • असली सवाल coverage number नहीं, बल्कि "आखिरी बार test ने production से पहले bug कब पकड़ा था?" होना चाहिए

5. first commit तक का समय (Time to First Commit)

  • नए engineer को laptop देने के बाद वास्तविक bug fix या छोटे feature वाला PR खोलने में कितना समय लगता है
    • स्वस्थ codebase: 1~2 दिन
    • drag से ग्रस्त codebase: 2 हफ्ते या उससे अधिक
  • एक client के यहाँ dev environment setup करने में कई हफ्ते लगते थे, लेकिन सुधार के बाद नए developers 15~20 मिनट में environment तैयार कर लेते थे
  • मुख्य कारण है setup rot — bin/setup script आखिरी environment change के बाद update नहीं किया गया, seed data ऐसी tables/columns को refer कर रहा है जो अब मौजूद नहीं हैं, और app चलाने पर crash होने के बाद ही पता चलने वाले 3 undocumented environment variables मौजूद हैं
  • मौजूदा engineers ये undocumented steps पहले से ही अपने काम में शामिल कर चुके होते हैं, इसलिए सिर्फ नए joiners ही ठीक-ठीक दिखाते हैं कि codebase कितनी implicit knowledge मांगता है

खराब codebase में अच्छे engineers धीमे क्यों दिखते हैं

  • ये 5 संकेत मिलकर असर करते हैं और हर काम में ऐसा overhead जोड़ते हैं जिसे standup में ठीक से pointed out नहीं किया जा सकता
    • जो engineer पिछली कंपनी में 2 दिन में feature बना देता था, उसे इस codebase में 1 हफ्ता लग सकता है, और वजह समझाने पर भी वह बहाना लग सकता है
  • 2025 METR research के मुताबिक, AI tools इस्तेमाल करते समय experienced developers 19% अधिक धीमे थे — यह इस बात का संकेत है कि bottleneck typing नहीं थी
  • सबसे अच्छे engineers जोखिम को बेहतर पहचानते हैं, इसलिए अधिक सावधानी से काम करते हैं और estimate को बड़ा रखते हैं — कम अनुभवी engineer जोखिम न देखकर जल्दी deploy कर देता है, production issue पैदा करता है, और पूरी टीम फिर और सतर्क हो जाती है; यह एक दुष्चक्र है
  • एक client ने 10 साल में 6 teams बदलीं (जिसमें 2 पूरी acquisitions भी शामिल थीं) — leadership की feature demand → debt work को टालना → code का unrecoverable हो जाना → rewrite या microservices split का प्रस्ताव → system का दो हिस्सों में बंटकर और खराब हो जाना, यह पैटर्न बार-बार दोहराया गया
  • जब leadership गति की गिरावट को talent problem मानती है, तो वह पहले से friction झेल रही टीम पर सिर्फ process और बढ़ा देती है, जिससे स्थिति और बिगड़ती है — वास्तव में मदद करने वाला एकमात्र हस्तक्षेप path को ही बदलना है

Codebase Drag Audit: diagnosis कैसे करें

  • 5ों संकेतों को 0~2 अंकों में score करें:
    • 0 अंक: कोई समस्या नहीं
    • 1 अंक: आंशिक समस्या
    • 2 अंक: गंभीर समस्या
  • 4 या उससे अधिक अंक होने पर किसी भी अन्य कदम से पहले codebase में सीधा निवेश किया जाना चाहिए

जब technical debt टीम को पीछे खींच रही हो, तब क्या करें

  • सबसे ऊँचे score वाले एक संकेत से शुरुआत करें — सब कुछ एक साथ ठीक करने की कोशिश न करें
    • deploy fear 2 अंक: पहले CI speed, rollback automation, और छोटे deploy units पर काम करें
    • apology estimate सबसे ऊपर: सबसे बड़े blast radius वाले module को decouple करना प्राथमिकता हो
    • first commit time 2 अंक: bin/setup ठीक करने और environment documentation पर 1 दिन लगाने से बाद की हर नई hiring में उसका लाभ मिल सकता है
  • अगर Rails version कई versions पीछे है, तो version upgrade निवेश को उचित ठहराने वाला forcing function बन सकता है
  • 2 हफ्ते के चक्र में मापें: सबसे ऊँचे score वाला संकेत चुनें → focused sprint चलाएँ → ठोस metrics मापें (deploy frequency, estimate accuracy, first PR time आदि)
  • निवेश के लिए approval मिलना मुश्किल इसलिए होता है क्योंकि न करने की लागत दिखाई नहीं देती — "technical debt है" कहने से ज़्यादा प्रभावी बात है, "इन 3 modules की coupling की वजह से हर feature में लगभग दोगुना समय लग रहा है"
  • 7 या उससे अधिक अंक आम तौर पर उस स्तर को दिखाते हैं जहाँ 1 हफ्ते के codebase audit से शुरुआत करनी चाहिए

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.