रोडमैप का काम रोककर bug fix पर केंद्रित एक हफ्ता

• लगभग 45 इंजीनियरों की टीम हर तिमाही एक हफ्ते के लिए रोडमैप, डिज़ाइन और मीटिंग्स रोककर ‘Fixit सप्ताह’ चलाती है, जिसमें छोटे bug और productivity समस्याओं को हल करने पर फोकस किया जाता है
• इस Fixit में 189 bugs ठीक किए गए, 40 लोगों ने भाग लिया, प्रति व्यक्ति median 4 और अधिकतम 12 bugs बंद किए गए
• 2 दिन के भीतर समाधान का नियम, points और leaderboard system, T-shirt rewards आदि के जरिए motivation और team morale बढ़ाया गया
• AI tools के उपयोग से code exploration और fix suggestions की रफ्तार बढ़ी, context switching का बोझ घटा
• Fixit को product polish बेहतर करने और team bonding मजबूत करने वाला अभ्यास माना गया, जो छोटी समस्याएँ सुलझाने की खुशी वापस लाता है

---

Fixit की अवधारणा और संचालन का तरीका

• Fixit हर तिमाही चलने वाला एक हफ्ते का focused bug-fixing period है, जिसमें नियमित रोडमैप काम, डिज़ाइन और मीटिंग्स पूरी तरह रोक दी जाती हैं
  • इंजीनियर उन छोटी गलतियों या productivity bottlenecks को ठीक करते हैं जो users और developers दोनों को परेशान करती थीं
  • उदाहरण: 2 साल से अस्पष्ट error message, scroll और zoom साथ इस्तेमाल करने पर आने वाला glitch, धीमे tests की वजह से CI delays
• इसके दो नियम हैं
  • कोई भी bug 2 दिन से ज़्यादा नहीं लेना चाहिए
  • काम का फोकस end-user improvements या developer productivity gains पर होना चाहिए
• Points system और leaderboard के जरिए भागीदारी को दिखाया जाता है, और ‘पहला bug fix’, ‘सबसे परेशान करने वाला bug fix’ जैसे अलग-अलग वर्गों में T-shirt rewards दिए जाते हैं

Fixit के नतीजे

• इस Fixit के परिणाम
  • 189 bugs ठीक, 40 प्रतिभागी, प्रति व्यक्ति median 4, अधिकतम 12
• प्रमुख उदाहरण
  • 2021 में दर्ज Perfetto की feature request को एक दिन में implement किया गया, जिससे user experience बेहतर हुआ
  • GitHub Action fix के जरिए UI developers के लिए build access पाने में लगने वाले clicks कम हुए
  • SDK integrated version उपलब्ध कराना से project integration आसान हुई, और यह लगभग 1 घंटे में implement किया गया

Fixit के प्रभाव

• Product स्तर पर: बारीकी और polish

  • अच्छे products की पहचान details पर ध्यान और consistency होती है
  • Fixit, ऐसे छोटे friction points हटाने का मौका देता है जिन्हें users सीधे नोटिस न भी करें, लेकिन उनसे product quality एक स्तर ऊपर जाती है

• व्यक्तिगत स्तर पर: execution-केंद्रित संतोष

  • करियर की शुरुआत में मिलने वाला “problem spotted → fixed → shipped” वाला तत्काल achievement feeling फिर से मिलती है
  • Fixit के दौरान ‘क्या बनाना है’ से ज़्यादा ‘क्या बेहतर करना है’ पर ध्यान रहता है, जिससे छोटे cycles में उपलब्धि जुड़ती जाती है

• Team स्तर पर: morale और collaboration मज़बूत

  • दो time zones में फैले 40 लोग एक साथ bug fixes करते हैं, जिससे पूरी organization की energy बढ़ती है
    • चैट में real-time fixes साझा करना, screenshots पोस्ट करना, demo दिखाना जैसी सक्रिय बातचीत होती है
  • हर सुबह fix count, participant count और leaderboard rank साझा किए जाते हैं, जिससे motivation और बढ़ता है

सफल Fixit चलाने की ज़रूरतें

• पहले से तैयारी

  • साल भर bugs को “good fixit candidate” के रूप में tag किया जाता है, और Fixit से पहले वाले हफ्ते में उन्हें small, medium, large (0.5, 1, 2 दिन) में classify किया जाता है
  • हर size के लिए 1, 2, 4 points दिए जाते हैं, और priority bug list बनाई जाती है
  • यही तैयारी पहले दिन की उलझन रोकने का मुख्य तत्व है

• 2 दिन की सीमा का नियम

  • पहले ऐसा हुआ कि एक bug अपेक्षा से ज़्यादा complex निकला और पूरा Fixit सप्ताह उसी में चला गया
  • उसके बाद 2 दिन से ज़्यादा होते ही रोककर backlog में भेजने का सिद्धांत अपनाया गया, ताकि लगातार उपलब्धि की भावना बनी रहे

• प्रतिभागियों की संख्या

  • शुरुआती 7 लोगों के स्तर पर नतीजे तो मिले, लेकिन पूरी organization में shared buy-in कम था
  • लगभग 40 लोगों पर critical mass बनती है, जहाँ collective energy और immersion अधिकतम हो जाते हैं

• Gamification

  • Points का मकसद accuracy से ज़्यादा fun है (1/2/4 points)
  • उपलब्धियों की व्यापक पहचान: पहला fix, सबसे परेशान करने वाला bug आदि
  • इसे performance review से अलग रखा जाता है, ताकि शुद्ध participation motivation बनी रहे
  • social norms और team size की वजह से system abuse के मामले लगभग नहीं के बराबर हैं

AI tools की भूमिका

• Fixit की मुख्य चुनौती context switching का बोझ है, जिसे AI कम करता है
  • संबंधित files जल्दी ढूँढना और उनका सार देना, जिससे cognitive load कम होता है
• उदाहरण
  • documentation fix PR: AI ने एक ही बार में fix suggestion दिया
  • Record page improvement: AI ने code prototype दिया, जबकि UX fixes हाथ से पूरी की गईं
• नतीजतन शुरुआती बिंदु तक पहुँचने की गति बढ़ती है, और कुछ मामलों में तुरंत fix करना संभव हो जाता है

Fixit पर आलोचनाएँ और जवाब

• “क्या इसका मतलब है कि bugs को सामान्य दिनों में नज़रअंदाज़ किया जाता है?”

  • कुछ हद तक यह सही है, लेकिन यह उस वास्तविकता की भरपाई करता है जहाँ छोटी असुविधाएँ (papercut bugs) priority में पीछे छूट जाती हैं
  • Fixit, “छोटी लेकिन महत्वपूर्ण” समस्याओं को हल करने के लिए स्पष्ट रूप से सुरक्षित समय देता है

• “क्या रोडमैप का काम रोकना बर्बादी नहीं है?”

  • 40 लोगों का 1 हफ्ते का investment बड़ा है, लेकिन product polish और user satisfaction में सुधार इसे संतुलित कर देता है
  • test speed improvements, clearer error messages, shorter workflows जैसी productivity gains लंबे समय तक असर करती हैं

• “क्या यह सिर्फ बड़ी कंपनियों के लिए संभव है?”

  • छोटे teams भी इसे ‘Fixit Friday’ या 2 दिन के mini Fixit जैसे रूपों में अपना सकते हैं
  • असली बात है focused, protected time और साझा सुधार गतिविधि

Fixit का मूल मूल्य

• आधिकारिक उद्देश्य है product quality और developer productivity बढ़ाना
• अनौपचारिक कारण है “कुछ ठीक करने की खुशी”
• इसे सरल समयों वाली संतुष्टि वापस लाने और ध्यानपूर्वक product बनाने की संस्कृति को बनाए रखने के लिए ज़रूरी तत्व माना गया है

[t7vonn]

मुझे बैमिन की pitstop संस्कृति याद आ रही है। सुना है कि अब यह नहीं रही।

[GN⁺]

Hacker News राय

• आइडिया पसंद है, लेकिन “बग को 2 दिन से ज़्यादा नहीं लगना चाहिए” वाली बात अजीब लगती है
  असल में बग ठीक करने से पहले यह अनुमान लगाना लगभग असंभव होता है कि कितना समय लगेगा
  हाँ, अगर बड़े refactoring की ज़रूरत न हो तो शायद एक दिन से ज़्यादा लगने वाली चीज़ कम ही होती है
  मैं आमतौर पर severity या priority के हिसाब से बग हैंडल करता हूँ। कई बार जितना गंभीर बग होता है, उतना ही आश्चर्यजनक रूप से आसानी से मिल भी जाता है
  कारण मिल जाए तो समाधान जल्दी हो जाता है

  • मैं पहले एक ऐसी कंपनी में काम करता था जो MS SQL Server बहुत इस्तेमाल करती थी, जहाँ हर कुछ महीनों में सर्वर क्लस्टर को रोक देने वाला एक Heisenbug आता था
    हमने सालों तक logs का विश्लेषण किया लेकिन कारण नहीं मिला, फिर पता चला कि एक खास state के DB और commit combination में यह 100% reproduce होता है
    NDA साइन करके हमने minimal reproducing binary बनाया और उसे PowerShell script से automate किया, तो एक महीने में MS ने उसे ठीक कर दिया
    अंदरूनी तौर पर वह buffer overflow जैसा लग रहा था, लेकिन पक्का नहीं था
  • जिन ज़्यादातर bug-heavy projects पर मैंने काम किया, वहाँ ऐसा नियम अनकहा तौर पर मौजूद था
    अगर पूरे हफ्ते सिर्फ बग ही ठीक किए और Jira में story points नहीं जोड़ पाए, तो कई managers आकर पूछते थे कि रफ्तार धीमी क्यों है
    इसलिए मैंने यह सीखा कि मुश्किल बग्स से बचो और जिन कामों से points नहीं मिलते, उन्हें जल्दी छोड़ देना बेहतर समझा जाता है
  • hardware साइड में काम करो तो मुश्किल से reproduce होने वाले बग कभी-कभी महीनों ले लेते हैं
    पता ही नहीं चलता कि समस्या code, compiler या hardware में है, और कई factors मिलकर बनने वाले complex bugs तो अकेले reproduce भी नहीं होते
  • game जैसे entangled architecture में अक्सर ऐसी complex structure होती है जहाँ event A, B को trigger करता है, लेकिन C की state के हिसाब से behavior बदल जाता है
    ऐसे मामलों में जल्दी के workaround जमा होते जाते हैं, और बाद में सही bug fix एक बड़े rework में बदल जाता है
  • बग के ठीक न होने के आम तौर पर दो कारण होते हैं
    1. कारण साफ़ नहीं होता, इसलिए ज़्यादातर समय उसे ढूँढने में जाता है
    2. कारण साफ़ होता है, लेकिन वह architectural mistake होती है, इसलिए fix बहुत बड़ा काम बन जाता है
       और low-trust environment में तो Jira process की वजह से मामूली बग भी तुरंत ठीक नहीं किए जा सकते

• Meta में काम करते समय हम हर quarter Fix-it Week करते थे
  शुरुआत में लगा कि leadership quality की परवाह करती है, लेकिन असल में यह technical debt जमा करने का लाइसेंस वाला समय था
  एक हफ्ता बग ठीक करने की कोशिश की, लेकिन पहले से जमा debt की वजह से लगभग कुछ भी हल नहीं हो पाया

  • इससे id Software की policy याद आती है — “अगर बग दिखे तो तुरंत ठीक करो”
    वरना नए code की परतें बग के ऊपर चढ़ती जाती हैं और वह unstable foundation बन जाता है
    John Romero की talk video में भी यही philosophy ज़ोर देकर कही गई है
  • Meta का Fix-it Week असल में refactoring week था
    developers पुराने TODO निपटाते थे और LOC बढ़ाते थे, और कुछ लोग जानबूझकर गलत code लिखकर बाद में उसे “ठीक” करने के तरीके से diff count बढ़ाने की चाल भी चलाते थे
  • जैसा मूल लेख में कहा गया है, Fix-it Week का फोकस छोटे बग या developer experience सुधारने पर होता है
    यानी ऐसे issues पर जो urgent नहीं हैं, लेकिन परेशान करते हैं
  • ऐसे हफ्ते उल्टा “अभी ठीक करने की ज़रूरत नहीं, Fix-it Week में कर लेंगे” जैसा मानसिक लाइसेंस बन जाते हैं
    leadership का ईमानदारी से business priority समझाना, और बग का users पर असर साफ़ दिखाना ज़्यादा ज़रूरी है
  • अगर सच में quality की परवाह है, तो feature development के भीतर स्वाभाविक रूप से bug fixes शामिल करना ही सबसे व्यावहारिक तरीका है

• feature development के दौरान urgent response और priority change का दोहराता हुआ दुष्चक्र मैंने भी देखा है
  आख़िर में सिस्टम workaround से भरा हुआ हो जाता है, और न ग्राहक खुश रहते हैं न developers
  ऐसी स्थिति में लगता है कि काश शुरुआत में ही रुककर मूलभूत bug fix किए होते

  • यह pattern अक्सर संगठनात्मक विघटन का典型 लक्षण होता है
    communication टूट जाता है, और leaders कटे सिर वाली मुर्गियों की तरह भागदौड़ करते हुए बस आदेश देते रहते हैं
    developer हर समस्या का फायरफाइटर बन जाता है, और अंत में निकल जाना ही एकमात्र उपाय बचता है
  • यह साफ़ तौर पर leadership failure है
    जैसे-जैसे गति घटती है, leader और ज़्यादा panic में आकर project को बार-बार इधर-उधर शिफ्ट करते हैं, जिससे अराजकता और toxic culture बढ़ता है
  • ऐसी स्थिति से बचने के लिए हर हाल में ग्राहकों को खुश करने की कोशिश करने के बजाय, expectation manage करने की क्षमता ज़रूरी है
  • लेकिन अगर कंपनी अभी भी PMF(Product-Market Fit) ढूँढने के चरण में है, तो perfect engineering पर बहुत समय लगाना शायद अक्षम भी हो सकता है
  • अंत में समस्या व्यक्ति नहीं, बल्कि विषाक्त संगठनात्मक संस्कृति है। जितनी जल्दी हो सके निकल जाना ही जवाब है

• मैंने हमेशा “bug fixes first” वाली philosophy के साथ काम किया है
  अगर मौजूदा features ठीक से काम नहीं कर रहे, तो नए features नहीं बनाता
  इससे bug-free codebase बनाए रखने में मदद मिलती है और team productivity भी बढ़ती है

  • लेकिन team जितनी बड़ी होती जाती है, बग्स से ज़्यादा नए feature development को प्राथमिकता देने की प्रवृत्ति उतनी मज़बूत हो जाती है
  • लोग अक्सर पूछते हैं कि ऐसी culture कहाँ संभव हुई
    खासकर frontend में तरह-तरह के environment issues की वजह से पूरी तरह bug-free state लगभग असंभव होती है
    और “bug” की परिभाषा भी धुंधली होती है, इसलिए managers कई बार अपने मनचाहे feature को भी bug की category में डाल देते हैं
  • बग्स की भी priority होती है
    उदाहरण के लिए, शायद ही इस्तेमाल होने वाले API page की error किसी नए feature से कम महत्वपूर्ण हो सकती है
  • बड़े user-base वाले systems में हज़ारों बग्स मौजूद होते हैं
    उनमें से ज़्यादातर मामूली होते हैं, इसलिए leadership को नए features ज़्यादा पसंद आते हैं
  • वास्तव में पूरी तरह zero-bug codebase जैसी कोई चीज़ नहीं होती। यह मान लेना कि बग नहीं हैं, बस जागरूकता की कमी है

• मैं एक छोटा SaaS product चलाता हूँ और “पहले बग ठीक करो” सिद्धांत का पालन करता हूँ
  नए features से पहले customer-reported bugs हल करता हूँ
  ऐसा करने से नए मिलने वाले बग धीरे-धीरे कम होते जाते हैं और fixes भी आसान हो जाती हैं
  business के लिहाज़ से यह inefficient हो सकता है, लेकिन quality और customer trust के नज़रिए से यह बेहतरीन strategy है
  जब customer द्वारा report किया गया bug कुछ घंटों में ठीक हो जाता है, तो उन्हें सच में बहुत अच्छा लगता है

  • लेकिन 15 साल पुराने legacy codebase में इस सिद्धांत को लागू करना मुश्किल है, इस पर एक सहकर्मी ने भी सहमति जताई
  • इस बारे में मेरा एक लेख है — Fix Bugs or Add New Features

• Fix-it Week जैसी व्यवस्था उल्टा bug fixes टालने को बढ़ावा दे सकती है
  “बाद में Fix-it Week में कर लेंगे” जैसा बहाना बन जाता है
  इसकी जगह quarter या sprint planning में maintenance time को साफ़ तौर पर शामिल करना बेहतर है
  इससे developers को तुरंत बग ठीक करने का आधार मिलता है और continuous improvement culture बनती है
  Fix-it Week को शायद छोटे improvements या POC शामिल करने वाले mini hackathon की तरह चलाना बेहतर होगा

• एक पुरानी कंपनी में हमेशा यही cycle दोहराई जाती थी

  1. feature development पर पूरा ज़ोर → 2) बड़े customer incident का होना → 3) पूरा development रोककर bug-fix week
     यह pattern गलत संगठनात्मक संस्कृति का संकेत था। अगर सामान्य समय में bug-fixing के लिए वक्त सुरक्षित नहीं किया जाएगा, तो कुछ भी नहीं बदलेगा

• इससे Joel Spolsky का Joel Test याद आता है
  उसका पाँचवाँ सवाल था, “क्या आप नया code लिखने से पहले bugs ठीक करते हैं?”
  25 साल बाद भी यह अब भी एक वैध कसौटी है
  मूल लिंक

• मेरा मानना है कि बग्स को points या size estimate नहीं देना चाहिए
  अगर ज़बरदस्ती score देना ही हो, तो सबको 2 दे दो, औसतन वही सही बैठेगा
  bug fixes को Kanban style में, महत्व के क्रम में हैंडल करो और उपलब्ध समय के भीतर पूरा करो

• मैं ही लेख का लेखक हूँ। इतनी सक्रिय चर्चा देखकर खुशी हुई

  1. बग की complexity का अनुमान लगाना मुश्किल होता है, इसलिए कुछ घंटे जाँचने के बाद अगर scope बढ़ता दिखे तो उसे दूसरे issue में बदलने की सलाह देता हूँ
  2. “bug” शब्द का इस्तेमाल हमने सिर्फ पारंपरिक errors के लिए नहीं, बल्कि feature improvement requests तक को शामिल करने वाले internal term की तरह किया
  3. Fix-it Week के “तब तक टाल दो” में बदल जाने का जोखिम है, लेकिन हम इसे सिर्फ छोटे बग्स के लिए चलाते हैं
     यह technical hygiene या बड़े issues सुलझाने का विकल्प नहीं है
  • एक प्रतिक्रिया में कहा गया कि लेख दिलचस्प था, और साथ ही यह सवाल भी पूछा गया कि bug fixes के कारण regressions या नए errors कितनी बार पैदा हुए