- डेवलपमेंट स्किल सिर्फ़ ज्ञान से तय नहीं होती; क्या करना चाहिए यह जानते हुए भी मोटिवेशन की कमी के कारण टेस्ट, रिफैक्टरिंग और reproduction case लिखना टालते रहें तो तकनीकी कर्ज़ जमा होता जाता है
- बेहतरीन डेवलपर flaky test की जांच करके उन्हें ठीक करते हैं, मिले हुए bug को ticket में बदलते हैं या तुरंत ठीक करते हैं, और अगर नई feature मौजूदा code से मेल नहीं खाती तो पहले refactoring करते हैं
- “premature optimisation”, “duplication is better than the wrong abstraction”, “Keep It Simple, Stupid” जैसे सूक्तियाँ वास्तविक constraints से निपटने में उपयोगी हैं, लेकिन इन्हें कभी-कभी सिर्फ़ करने का मन न होने को छिपाने के लिए भी इस्तेमाल किया जा सकता है
- Lazygit में कई महीनों में end-to-end test system बनाया गया और उसका असर महसूस हुआ, लेकिन Lazydocker में वही test नहीं जोड़े गए, और minimum reproduction repository की request व God Struct refactoring भी टलती रही
- जब परफेक्ट code लिखने की ऊर्जा न हो, तब भी कमी को ईमानदारी से सामने रखने पर maintenance के मानदंड और अगले काम की प्राथमिकता तय करना आसान हो जाता है
तकनीकी कर्ज़ पैदा करने वाली मोटिवेशन की कमी
- “Can’t Be Fucked” एक ऑस्ट्रेलियाई slang है, जिसका मतलब है किसी काम को करने का मन न होना या उसके लिए ऊर्जा और मोटिवेशन न होना
- मुझे लगता था कि डेवलपमेंट का ज़्यादा ज्ञान सीख लेने से मैं बेहतर programmer बन जाऊँगा, लेकिन जिन डेवलपरों का मैं सच में सम्मान करने लगा, वे सिर्फ़ ज्ञानवान नहीं बल्कि लगातार ईमानदार मेहनत करने वाले लोग थे
- अच्छे डेवलपर जानते हैं और उसी के अनुसार काम करते हैं कि समस्या छोटी हो तभी उसे सही तरीके से संभाल लेना, लंबे समय में समय बचाता है
- अगर flaky test हो तो उसकी जांच करके उसे ठीक करते हैं
- production में bug मिले तो ticket बनाते हैं या तुरंत fix करते हैं
- नई feature मौजूदा code से फिट न बैठे तो उसे ज़बरदस्ती ठूँसने के बजाय पहले refactor करते हैं
- ज़रूरत पड़े तो stack के नीचे तक जाकर root cause समझते हैं
- ऐसे डेवलपर यह भी समझते हैं कि कब “good enough” सही है, कब scope घटाना चाहिए, और कब domain को और समझ लेने के बाद architecture बदलना बेहतर होगा
- समस्या यह है कि ऐसे फैसलों से अलग, कुछ मौकों पर प्रोजेक्ट के बाहरी constraints से भी बड़ा constraint मोटिवेशन की कमी बन जाता है
सूक्तियों के पीछे छिपने के बजाय ईमानदार बनना
- Lazygit का end-to-end test system कई महीनों तक part-time बनता रहा, बाद में उसने बहुत से regression रोके, और मुझे यक़ीन है कि अगर उसे अब जोड़ना पड़े तो यह और कठिन होता
- इसके बावजूद Lazydocker में end-to-end test न जोड़ने की वजह सिर्फ़ CBF थी
- दूसरे open source repository में issue दर्ज करने के बाद minimum reproduction Git repository माँगी गई, लेकिन वह अब तक नहीं बनाई गई; और एक साल से ज़्यादा पहले शुरू की गई बड़ी refactoring भी पूरी नहीं हो पाई, इसलिए code का बड़ा हिस्सा अब भी God Struct में पड़ा है
- यह burnout है, growth mindset की कमी है, या व्यक्तित्व का मामला है — इस पर कोई अंतिम निष्कर्ष नहीं दिया गया है
- तकनीकी कर्ज़ के लंबे दर्द को जानना टालने की प्रेरणा बन सकता है, लेकिन जानना और वास्तव में सही व्यवहार करना, दोनों अलग बातें हैं
- “बहुत ज़्यादा test से maintenance का बोझ बढ़ता है”, “दूसरी feature का क्या असर होता है यह देखकर refactor करूँगा”, “premature optimisation”, “cut scope aggressively” जैसी बातें अच्छे निर्णय के लिए भी कही जा सकती हैं, लेकिन बहाने के तौर पर भी इस्तेमाल हो सकती हैं
- अगर यह मान लिया जाए कि code या pull request का कोई हिस्सा सिर्फ़ आलस्य की वजह से कमज़ोर है, तो reviewer सीधे तय कर सकता है कि वह कमी स्वीकार्य सीमा के भीतर है या अगला काम करने में समय लगाना बेहतर होगा
- जब CBF की स्थिति आए, तो हताश होने के बजाय ईमानदार होना चाहिए; और अगर बहुत लंबे समय से 100% पर दौड़ रहे हों, तो शायद छुट्टी की ज़रूरत हो सकती है
1 टिप्पणियां
Hacker News की राय
CBF का बड़ा हिस्सा सिर्फ compensation और incentives से समझाया जा सकता है
जब मैं इस कंपनी में आया था, तो ऊर्जा से भरा हुआ था: टूटे हुए build ठीक किए, उपेक्षित tests पास कराए, deployment pipeline refactor की, और bugs की root cause खोजकर ठीक की
लेकिन समय के साथ, लोगों ने मुझसे सीखने के बजाय यह मान लिया कि “वैसे भी वह व्यक्ति ठीक कर देगा”, और मुझे समझ आ गया कि छोटे-मोटे गंदे काम करने पर बदले में बस और ज्यादा वही काम मिलते हैं
इसके उलट जो लोग जल्दबाजी में hack की तरह चीजें बनाते हैं, वे नतीजों को अच्छे से package करके पहले promotion पा लेते हैं, और जब operations में समस्याएँ फूटती हैं तब तक वे किसी दूसरे project पर जा चुके होते हैं
जिस junior की मैं हर हफ्ते कई घंटे मदद करता हूँ, वह 2022 में जल्दबाजी में hiring के कारण मुझसे ज्यादा कमाता है, और मुझे 2023 में “expectations से ऊपर” rating मिली, लेकिन कठिन समय का हवाला देकर raise भी नहीं मिला
आखिरकार, salary पर काम करने वाले व्यक्ति के तौर पर अगर मेहनत का reward न मिले या उल्टा सजा मिले, तो motivation खत्म होना अजीब नहीं है
छोड़कर जाएँ, और ऐसी जगह और अपने लोग खोजें जहाँ आप सच में belong करते हों
recognition मिलने पर motivation cost बहुत कम हो जाती है, और लोगों को rewards पसंद होते हैं
लोग games में हजारों घंटे इसलिए लगाते हैं क्योंकि motivation cost बहुत कम होती है
मेरा मतलब workplace को gamify करने से नहीं है, लेकिन खुद की पैरवी करना petty लग सकता है, इसलिए colleagues को एक-दूसरे को recognize करना चाहिए
technical debt में भी अलग-अलग interest rates होते हैं, और skill इस बात में है कि 0% debt को छोड़कर high-interest debt पहले चुकाया जाए
basement की closet का floor बिछाते समय material कम पड़ गया, इसलिए पीछे तक पूरी तरह नहीं बिछा पाया; देखने में थोड़ा बदसूरत है, लेकिन हमेशा boxes से ढका रहता है और दशकों तक रहने पर भी असर नहीं पड़ता। यह 0% technical debt है
इसके उलट अगर drain बंद हो जाए, तो समय के साथ basement leakage या drain के टूटकर गिरने से cost बढ़ती जाती है, इसलिए यह interest वाला debt है। entrance stairs खराब होकर बार-बार ठोकर लगवा रही हों तो वह भी high-interest debt है जिसे जल्दी ठीक करना चाहिए
engineering में, ऐसी architecture problem जो हर feature development को धीमा कर दे, high-interest debt हो सकती है; और किसी शायद ही छुए जाने वाले file में messy code या TODO असल में low-interest debt हो सकता है
engineers एक तरफ 0% debt ठीक करने में ज्यादा जरूरी काम चूक जाते हैं, और दूसरी तरफ कहते हैं कि “product/leadership technical debt हल करने में support नहीं करती”, लेकिन अक्सर वे actual cost और interest rate ठीक से समझा नहीं पाते
ऊपर से नीचे तक सबका ध्यान सिर्फ नई और चमकदार चीजों पर जाता है, existing चीजों को maintain करने में किसी की रुचि नहीं होती
भले ही आप importance समझा दें, management बस यह मान लेती है कि वह काम जरूरी है, लेकिन performance review पर उसका कोई positive impact नहीं होता। अगर कुछ गलत हो जाए तो डाँट खाने वाला काम मुझे ही उठाना पड़ता है
अगर codebase messy और inconsistent हो, तो hidden files में भी developers की इच्छा कम हो जाती है कि वे नए features consistency और quality के साथ implement करें
बात यह बन जाती है कि “वैसे भी इस पूरे module को फिर से लिखना है, तो फिलहाल इसे यहाँ rough तरीके से जोड़ देते हैं, बाद में clean up करेंगे”
https://en.wikipedia.org/wiki/Broken_windows_theory
यह technical debt शब्द का natural extension है, और बात को संक्षेप में असरदार ढंग से बताती है, इसलिए इसे company में भी इस्तेमाल करना चाहूँगा
इसलिए “developer actual cost समझा नहीं पाया” कहना थोड़ा आसान बहाना है
अगर customer-facing समस्या आती है तो उसके solve होने की संभावना होती है, लेकिन अगर वह सिर्फ internal problem है तो संभावना बहुत कम हो जाती है
जब “0% technical debt” जैसे expression को गंभीरता से इस्तेमाल किया जाता है, तो सोचना चाहिए कि कहीं concept ही गलत तो नहीं पकड़ लिया
debt वह है जिसे चुकाना पड़े या जिस पर interest देना पड़े; अगर ऐसा कुछ नहीं है, तो वह debt नहीं है
अगली बार क्या अभी implement न किए गए features को भी 0% technical debt कहेंगे?
मैं Steve Jobs का फैन नहीं हूं, लेकिन craftsmanship और details की परवाह करने वाले उनके quotes मुझे हमेशा पसंद आए हैं
“अगर आप एक carpenter हैं जो खूबसूरत chest of drawers बना रहा है, तो आप पीछे की तरफ plywood इस्तेमाल नहीं करेंगे, भले ही वह दीवार की तरफ हो और कोई उसे देख न सके. आपको पता है कि वह वहां है, इसलिए पीछे भी आप सुंदर लकड़ी ही लगाएंगे. रात को चैन से सोना है तो aesthetics और quality आख़िर तक बनी रहनी चाहिए”
मुझे लगता है कि software पूरी तरह इस रवैये से बहुत पीड़ित है कि “requirements को technically बस किसी तरह पूरा कर दिया, तो मेरा काम खत्म”
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
कहा जाता है कि वे standards पर खरे न उतरने वाले hardware और software को release करने से मना कर देते थे, और सही specifications के हिसाब से न बना पाने वाले लोगों को निकाल भी देते थे
दूसरी तरफ, ज़्यादातर लोग ठीक उलटी leadership के तहत काम करते हैं: “जितनी जल्दी हो सके खत्म करो ताकि और बेच सकें, और quality test बस पास हो जाए इसके लिए जो ज़रूरी हो, उतना जैसे-तैसे मिला दो”
असली carpenter को बाजार में compete करने के लिए practical और cost-efficient होना पड़ता है
जहां कोई नहीं देखता वहां महंगी लकड़ी लगाना या extra समय लगाना throughput घटाता है और customer की cost बेवजह बढ़ाता है
कारीगर के पास भी समय और पैसा सीमित होते हैं, और अदृश्य काम पर लगाया गया समय, ज्यादा दिखने वाले काम पर न लगाया गया समय है
ऐसे market में जहां समान skill वाले carpenters कम cost में ज्यादा produce करते हैं, ऐसा carpenter पीछे छूट जाएगा
मुझे लगता है software की समस्या attitude से ज्यादा incentive problem है. अच्छा काम करना और अच्छा software इस्तेमाल करना मुझे पसंद है, लेकिन दिन में समय सीमित है और मैं ऐसे business benefit के लिए अपना personal time छोड़ने को तैयार नहीं हूं जिससे मुझे फायदा नहीं मिलेगा
ऊपर से, अगर refactoring शुरू करूं तो यह reasonably expect किया जा सकता है कि किसी दिन अचानक कोई जरूरी feature आ जाएगा जिसे आज ही खत्म करना होगा
management technical debt ठीक करने पर सहमत भी हो, तब भी आखिर में estimates फुलाए बिना और assigned काम की जगह refactoring किए बिना यह हल नहीं होता
किसी किताब में एक blacksmith character carriage का part ठीक करते हुए कहता है, “हमेशा जितना अच्छा कर सकते हो, उतना करो”
जब कहा जाता है, “वह तो नीचे लगने वाला part है, कोई देख नहीं पाएगा,” तो वह जवाब देता है, “लेकिन मुझे पता है कि वह वहां है. अगर मैं उसे अपनी क्षमता भर अच्छी तरह न बनाऊं, तो हर बार वह carriage गुजरेगी तो मुझे शर्म आएगी. और मैं उस carriage को हर दिन देखूंगा”
https://news.ycombinator.com/item?id=28086786
अगर आप सही unit/integration/end-to-end tests लिखते हैं, और messy code देखकर उसके ऊपर और जोड़ने के बजाय refactor करते हैं, तो कागज पर आपकी productivity उस colleague से कम दिखती है जो लगातार tickets “resolve” करता रहता है
यह खासकर उन “pure agile” organizations में बुरा है जहां refactoring या code quality cleanup को बिल्कुल consider नहीं किया जाता
Apple कम-से-कम एक समय exception था. product prices ऊंचे थे इसलिए customers quality expect करते थे, company के पास इसे संभव बनाने वाले margins थे, और सबसे बढ़कर Steve Jobs थे जिनकी experience पर नजर थी
दूसरे extreme पर Juicero जैसे उदाहरण हैं, जिसने juice pack निचोड़ने की machine aerospace-grade engineering से बनाई
career के ज्यादातर हिस्से में, जब भी मौका दिखा मैंने बिना कहे technical debt साफ किया. क्योंकि attachment और ownership का sense था
अब Jira-based micromanagement और autonomy-less workplace है, इसलिए जो बिल्कुल करना है उसके अलावा कुछ नहीं करता
पहले voluntary effort career का core था, लेकिन अब किसी भी change की bureaucratic और social project-management cost इतनी ज्यादा है कि करने लायक नहीं रह गया
product long term में अच्छा करता है या company सफल होती है, इससे मुझे फर्क नहीं पड़ता; अगली job मिलने तक बस tickets निपटाता हूं
उल्टा अगर “refactoring की permission मत मांगो, बस करो” वाली approach अपनाओ, तो repository के existing patterns follow न करने वाला PR बनाने के लिए डांट पड़ती है
फिर बात होती है, “अच्छा है, लेकिन हमें पूरी team से discuss करना होगा”
इसलिए technical debt बढ़ता रहता है, एक PR merge करने में महीनों लगते हैं, और tests इतने unstable होते हैं कि build होने तक restart button दबाना casino slot machine जैसा हो जाता है. Agile सच में कमाल है
सिर्फ reactive तरीके से चलने वाले workplace में proactive action मेरे अनुभव में कभी reward नहीं होता
कोई problem दिखाओ तो उसी पल वह मेरी problem बन जाती है, और बाद में फिर फूट पड़े तो माना जाता है कि मैंने ही बिगाड़ा
PMs और management हमेशा negative assumptions से चलते हैं, इसलिए worth it नहीं है
खासकर क्योंकि कुछ लोग सोचते हैं कि अच्छे code तक पहुंचने का कोई enlightened path उनके पास है, जबकि असल में वे अक्सर existing code को पढ़ने और समझने से आसान रास्ता चुनते हैं
यहां comments में थोड़ी misunderstanding है
individual programmer के लिए motivation, effort, energy, willpower—जो भी नाम दें—सीमित संसाधन हैं, और यह पूरी तरह normal है
organization की strength यह है कि वह individual programmer से ज्यादा काम करवा सकती है, लेकिन कई elements को जोड़ने की process में gaps बनते हैं और काम उन gaps से फिसल जाता है
COO, HR, product manager जैसे लोग, जिन्हें technical work के बजाय organization चलाने के लिए salary मिलती है, उन्हें उन gaps को संभालने के processes बनाने चाहिए
लेकिन increasingly ज्यादा companies यह काम individual engineers और designers पर डाल रही हैं, क्योंकि इसे P&L या OKR से measure करना मुश्किल है
company suffer करती है और engineers burnout हो जाते हैं. बिना extra compensation के gaps से फिसले छोटे tickets और tasks को लगातार संभालते रहने की भी एक limit होती है
यहाँ नकारात्मक माहौल बहुत ज़्यादा है, लेकिन यह लेख मेरी रोज़मर्रा की भावनाओं को बिल्कुल सही तरह से समझाता है, इसलिए अच्छा लगा
ओपन सोर्स प्रोजेक्ट्स की शानदार test coverage और सिद्धांतों पर आधारित refactoring देखकर मैं भी कुछ दिनों में “ठीक से करते हैं” मोड में आ जाता हूँ और बहुत सारी अच्छी चीज़ें बना लेता हूँ
फिर किसी दिन जब वह energy खत्म हो जाती है, तो लेखक की तरह मैं भी CBF हो जाता हूँ। tests छोड़ देता हूँ, ऐसी जगह code जोड़ देता हूँ जहाँ मुझे पता है कि यह सही नहीं है, और अपने भविष्य के लिए ऐसा रास्ता बना रहा होता हूँ जिसके लिए future-me शुक्रगुज़ार नहीं होगा
यह सब real time में दिखता है, फिर भी फिर से प्रेरित “ठीक से करते हैं” मोड में लौटने की energy या motivation नहीं होती
यह सब उस software में भी होता है जिसे मैं खुद बनाता और बेचता हूँ
यह देखकर प्रभावित हुआ कि लेखक Lazygit बनाने वाले व्यक्ति हैं, और मुझे lazygit सच में बहुत पसंद है। मेरे दिमाग में वे हमेशा उन open source maintainers की category में आते हैं जो चीज़ें ठीक से करते हैं
लगता है motivation को लेकर हम दोनों का अनुभव मिलता-जुलता है
खुशी है कि तुम्हें lazygit पसंद है, और उम्मीद है कि आगे भी उसकी अच्छी reputation बनाए रख पाऊँगा
ज़्यादातर फैसले असल में अवचेतन होते हैं
“अब बिल्कुल नहीं हो पाएगा” वाली स्थिति का मतलब है कि दिमाग का कोई circuit यह तय कर रहा है कि refactoring या tests जैसे काम करने लायक नहीं हैं
वह circuit सही भी हो सकता है। क्योंकि objective और overall तौर पर देखें तो कई बार effort के मुकाबले reward वाकई काफी नहीं होता
उदाहरण के लिए, अगर end-to-end tests बनाने में दो महीने लगे और अगले 6 महीनों में debugging वगैरह में सिर्फ 3 हफ्ते बचे, तो हिसाब नहीं बैठता
दो आम चरम स्थितियाँ हैं। एक तरफ business engineers पर ऐसा technical debt थोपता है जो सच में खराब trade-off होता है, और दूसरी तरफ engineers भी कभी-कभी ideal structure और बहुत बड़े test suites पर समय लगाते हैं जिनका अंत में reward नहीं मिलता
इसका एक हिस्सा यह भी है कि लोग डरते हैं कि कोई बेहतर code structure या extra tests खोजकर उनका evaluation करेगा
अगर मुझे लगता है कि मैं अपने standards से नीचे की चीज़ ship कर रहा हूँ, भले ही वे standards वास्तविक जरूरत से ऊँचे हों, तो morale और motivation को बड़ा नुकसान होता है
मुझे लगता है technical debt की सबसे बड़ी समस्या यही है कि यह morale खराब कर देता है
Lazygit में end-to-end test system को कई महीनों तक आंशिक रूप से बनाया था, और मैं हर दिन सोचता हूँ कि उस system ने कितने regressions रोके और अगर आज उसे जोड़ना पड़ता तो यह कितना ज्यादा मुश्किल होता
मुझे साफ पता है कि वह value वाला काम था, फिर भी Lazydocker में end-to-end tests क्यों नहीं जोड़े, तो बस इसलिए कि CBF है
end-to-end tests, अगर tools सही न हों, तो नरक जैसी झंझट और बहुत बड़ा काम होते हैं। ऐसे basic frameworks बेहतर होने चाहिए जिन्हें आसानी से plug in किया जा सके
अगर किस्मत अच्छी हो तो उस व्यक्ति के पास integration tests देखने का भी समय बचता है
इस society और दुनिया में लोगों को lazy कहने वाला नजरिया मुझे आम तौर पर बेतुका लगता है
दशकों तक हफ्ते में 40 घंटे काम करो और फिर पुनर्जन्म लेने के बाद आराम करो—ऐसे में laziness की बात करना ही अजीब लगता है
mental energy दूसरों की wealth बनाने में निचोड़ ली जाती है, और जब इतने बूढ़े हो जाते हैं कि कुछ कर नहीं सकते, तो छोड़ दिए जाते हैं
हर हफ्ते एक और feature आ जाता है जो कल ही खत्म हो जाना चाहिए था, तो समझ नहीं आता technical debt कब ठीक करना है। खाली समय में? वैसे भी पता नहीं हम लगातार exist क्यों करते रहें
एक छोटी team के mature project में बचे हुए tickets सब ऐसे मुश्किल bugs थे जिन्हें कोई नहीं चाहता था
कई दिन लगाने के बाद भी दिखाने को सिर्फ suspicious चीज़ों की list से कुछ items हटाने के अलावा कुछ नहीं होता, और अगर गलती से हटाया तो वही bug एक हफ्ते बाद फिर लौट आता
हर दिन सारी mental energy ऐसे tickets में डालनी पड़ती, और coffee या stimulants के सहारे किसी तरह bug हल कर भी लिया तो code submit करो, ticket बंद करो, और तुरंत अगले ticket पर जाओ
असली आराम नहीं होता; अगले ticket की शुरुआत में जब कोई तुरंत result की उम्मीद नहीं करता, तभी थोड़ी देर दिमाग को आराम मिलता
लेकिन कुछ दिन बाद लोग पूछने लगते कि अब तक क्या किया, कहीं अटके हो क्या, और असल में लगभग शुरू भी नहीं किया होता तो पीछे रहने की वजह के लिए छोटे झूठ गढ़ने पड़ते
जब सबसे ज्यादा आराम की जरूरत होती है, तब तक आप पहले से ही सबसे ज्यादा पीछे होते हैं और लोग नोटिस कर चुके होते हैं, इसलिए छुट्टी लेना भी कोई option जैसा नहीं लगता
अब एक engineering nonprofit में हफ्ते में 20–30 घंटे, कभी-कभी उससे भी कम काम करता हूँ, पैसे tight हैं, लेकिन इससे ज्यादा काम करना बिल्कुल संभव नहीं
side projects और cycle चलाने के लिए थोड़ा समय है, और weekends पर कभी काम नहीं करता। Tuesday को भी, कोई खास स्थिति न हो तो काम नहीं करता
मुझे अपनी current job सच में बहुत पसंद है और यह dream job है, लेकिन इसे करते हुए खुद को खत्म करना लायक नहीं। जिंदगी एक ही बार मिलती है, और मैं इसे ठीक से प्यार करते हुए जीऊँगा
आज मैंने company device firmware का लगभग पूरा rewrite वाला 1 महीने का काम खत्म किया, जबकि शुरुआत में इसे communication module के एक छोटे bug को ठीक करने वाला 1 हफ्ते का काम माना गया था
अच्छी बात है कि relaxed PM और colleagues हैं, इसलिए उन्होंने माना कि अब उस code के 8 साल पुराने legacy bugs सच में ठीक किए जा सकते हैं
अभी edge case tests और extra fixes बाकी हैं, लेकिन remote code update चल रहा है, इसलिए devices ship किए जा सकते हैं
यहाँ “झूठ” लगभग action recommendation जैसा है। असल में मैंने comment “झूठ बोलो” से शुरू किया था, लेकिन गलतफहमी हुई थी
colleagues को यह बताने के लिए भी exist करना चाहिए कि काम के broader implications पर सोचने के लिए समय लेना जरूरी है
ऐसी communities में अपने विचार जोड़ने, chocolate खाने, हो सके तो कुत्ते को walk कराने, और YouTube पर Alan Watts के lectures सुनने के लिए भी exist करना चाहिए
ठीक से करने की कोशिश करने वाले व्यक्ति के रूप में, मुझे लगता है technical debt में सबसे अहम चीज़ tracking है
दिख रही समस्या को एक task के रूप में डालने में कुछ ही मिनट लगते हैं, और वही task technical debt बन जाता है
leadership की जिम्मेदारी है कि technical debt की priority तय करे और लगातार एक तय मात्रा कम करती रहे
कभी-कभी किसी काम को न करने का फैसला करके भी technical debt घटाया जाता है, और वह भी पूरी तरह ठीक है
record करने, check करने और handle करने की प्रक्रिया का मकसद “अभी नहीं” वाली समस्या को दूसरी बार देखने का मौका देना है
पहली gut feeling गलत हो सकती थी और X की जरूरत नहीं रही होगी, या उल्टा, उस समय न सूझे किसी कारण से वह सही भी हो सकती थी
सबसे बढ़कर, “अभी नहीं कर सकते” वाली चीज़ों में से कुछ सच में महत्वपूर्ण होती हैं। समय निकालकर उन्हें देखे बिना ऐसी चीज़ें मिल नहीं सकतीं