- Dependency मुफ़्त feature जैसी दिख सकती है, लेकिन वास्तव में उसके साथ कई तरह की लागत और जटिलताएँ आती हैं
- गलत dependency learning curve, अचानक interface changes, deployment·installation समस्याएँ जैसी कई risks पैदा कर सकती है
- एक प्रमुख उदाहरण के तौर पर TigerBeetle security, performance और operational simplicity के लिए "zero dependency" policy अपनाता है
- लेखक dependency evaluation framework (ubiquity, stability, depth, ergonomics, watertightness) प्रस्तावित करते हैं
- अच्छी और खराब dependency में अंतर करने के लिए critical thinking, और dependency चुनते समय short-term productivity ही नहीं बल्कि कुल लागत और जोखिम को ध्यान में रखते हुए सावधानी से निर्णय लेना ज़रूरी है
NIH (Not Invented Here) से भी ज़्यादा महंगी है गलत dependency
dependency के नुकसान और छिपी हुई लागत
- कई developers dependency जोड़ने को "मुफ़्त feature" की तरह देखते हैं, लेकिन वास्तव में इसकी ये लागतें होती हैं
- सीखने में लगने वाला समय और जटिलता
- कई बार dependency को install करना ही मुश्किल होता है
- major version upgrade के समय अपने code में भी बड़े बदलाव करने पड़ते हैं
- dependency को आख़िरकार deployment/installation environment में शामिल करना ही पड़ता है (container, bundling आदि जैसी जटिलता पैदा होती है)
- गलत dependency अपनाने से core functionality से असंबंधित जटिल deployment structure भी बन सकता है
TigerBeetle का zero dependency सिद्धांत
- TigerBeetle Vanilla Zig पर आधारित एक financial database है, जो zero dependency policy अपनाता है
- यह केवल Zig language में विकसित होता है, और Zig toolchain के बाहर कोई external dependency नहीं रखता
- मकसद dependency से जुड़े supply chain attack risk, performance degradation, installation time बढ़ने जैसी समस्याओं से बचना है
- जो software infrastructure में जितना गहराई से जड़ें जमाता है, उसमें dependency की लागत पूरे stack में बढ़कर फैलती है
- standardized छोटे toolbox का उपयोग maintenance और development efficiency के लिए फ़ायदेमंद है
- Zig के साथ नए problems को तेज़ी से handle करने और complexity कम करने पर फ़ोकस किया जाता है
dependency evaluation framework
- लेखक मानते हैं कि हर developer के लिए पूरी तरह dependency-free होना संभव नहीं है, फिर भी dependency का सावधानी से मूल्यांकन करना ज़रूरी है
- लेखक dependency को इन 5 मानदंडों पर परखने का सुझाव देते हैं
- Ubiquity: target environment में यह कितनी आम है? क्या अलग से deploy/install करना पड़ेगा?
- Stability: backward compatibility, API change की आवृत्ति, support बंद होने जैसी समस्याएँ कितनी बार आती हैं?
- Depth: API के नीचे वास्तव में कितनी functionality छिपी है, और इसे खुद implement करना कितना कठिन होगा?
- Ergonomics: क्या API intuitive/declarative है और इस्तेमाल में आसान है, documentation कैसी है?
- Watertightness: abstraction कितनी अच्छी तरह काम करती है, और नीचे की technology की कितनी कम चिंता करनी पड़ती है?
- development community अक्सर सिर्फ usability पर चर्चा करती है, जबकि बाकी चार पहलू अक्सर नज़रअंदाज़ हो जाते हैं
अच्छी dependency के उदाहरण
-
POSIX system calls
- सार्वभौमिकता: Linux, Android, macOS, BSD आदि लगभग सभी platforms पर उपलब्ध
- स्थिरता: interface compatibility बहुत ऊँची, बदलाव लगभग नहीं
- गहराई: एक single API, kernel code की सैकड़ों हज़ार lines छिपा देता है
- उपयोगिता: थोड़ा पारंपरिक C style है, लेकिन इस्तेमाल में बड़ी दिक्कत नहीं
- पूर्णता: ज़्यादातर मामलों में ठीक, हालांकि storage में data persistence जैसी कुछ बारीक समस्याएँ हैं
-
ECMA-48 terminal control codes
- सार्वभौमिकता: Windows के cmd.exe को छोड़कर अधिकांश terminals में support
- स्थिरता: 1991 के बाद कोई बदलाव नहीं
- गहराई: ऐसा standard खुद बनाना बेहद कठिन
- उपयोगिता: Esc character की वजह से थोड़ा पढ़ने में कठिन, बाकी ठीक
- पूर्णता: hardware dependency की चिंता बहुत कम
-
web platform (Web API, HTML, JS, CSS आदि)
- सार्वभौमिकता: web browsers दुनिया के लगभग हर environment में installed हैं
- स्थिरता: मजबूत backward compatibility policy
- गहराई: अपना browser बनाना व्यावहारिक रूप से लगभग असंभव जितना गहरा क्षेत्र
- उपयोगिता: कुछ complexity है, लेकिन documentation और developer tools उत्कृष्ट हैं
- पूर्णता: file, audio, video जैसी विशेष स्थितियों को छोड़ दें तो बहुत high level की completeness
निष्कर्ष
- copy-and-paste, dependency के अति-उपयोग की बजाय critical thinking और कुल लागत के विश्लेषण की ज़रूरत है
- dependency अपनाते समय हर dependency की लागत और फ़ायदे का आलोचनात्मक मूल्यांकन करना चाहिए,
और पूरे system के संभावित जोखिम और लागत को भी ज़रूर ध्यान में रखना चाहिए; लंबी अवधि में यही कहीं सस्ता और सुरक्षित विकल्प है
2 टिप्पणियां
TigerBeetle: अकाउंटिंग के लिए विशेषीकृत OLTP डेटाबेस
Hacker News राय
मैंने पहली बार TigerBeetle का उदाहरण सुना, इसलिए खुद जाकर देखा। अगर आप safety और performance-क्रिटिकल, Zig-आधारित financial ledger database बना रहे हैं, और एक CPU core पर प्रति सेकंड दस लाख transactions संभालने हैं, तो dependency जोड़ने से बचना पूरी तरह तर्कसंगत है क्योंकि जोखिम बड़ा है। लेकिन ज़्यादातर सामान्य developers साधारण CRUD systems बनाते हैं, और आम तौर पर वे इतने मजबूत नहीं होते। बहुत-सी dependencies bugs से भरी हो सकती हैं, लेकिन कई बार उनकी quality उस चीज़ से बेहतर होती है जो अधिकांश developers खुद बनाते। कंपनियाँ भी व्यवहार में उन developers के स्तर से bottleneck हो जाती हैं जिन्हें वे hire कर सकती हैं। हर किसी की स्थिति अलग होती है, इसलिए यह याद रखना चाहिए कि परस्पर विरोधी सलाह भी अपने-अपने संदर्भ में सही हो सकती है
मैं वास्तव में TigerBeetle में काम करता हूँ। यहाँ मुख्य बात context है। TigerBeetle और rust-analyzer, दोनों में मजबूत developer culture है, लेकिन वे अलग समस्याएँ हल करते हैं इसलिए उनकी संस्कृतियाँ भी अलग हैं। लेख में जिन dependencies का ज़िक्र है, वे POSIX, ECMA-48, web platform जैसी चीज़ें हैं, जो library कम और system interfaces ज़्यादा हैं। Library dependency में समस्या आए तो उसे दोबारा लिख लेना संभव है, लेकिन system interface जैसी बुनियादी चीज़ें बदलना लगभग असंभव या बहुत महँगा होता है। अपने software के scope से बाहर की चीज़ें न करने का निर्णय बहुत शक्तिशाली होता है। उदाहरण के लिए, अगर कोई टीम matrix multiplication code बनाने में विशेषज्ञ है, तो वह core business से असंबंधित दूसरी libraries बाहर की ले सकती है, लेकिन मुझे लगता है कि product की responsibility decomposition बेहतर तरह से design करनी चाहिए। इससे system के भीतर आवश्यक dependencies को बेहतर isolate किया जा सकता है
इस दृष्टिकोण की समस्या यह है कि यह तभी सही लगता है जब आप केवल सबसे निचले स्तर के developers को ध्यान में रखें। Tech field में सलाह को सबसे कमज़ोर स्तर के हिसाब से dilute करने की प्रवृत्ति है, लेकिन सच कहूँ तो जहाँ-जहाँ मैंने काम किया, वहाँ ऐसा माहौल लगभग कभी नहीं था जहाँ developers किसी टूटी dependency को fork करके समस्या हल करने लायक भी न हों। CRUD को लेकर बहुत तिरस्कार होता है, लेकिन खराब abstractions CRUD में भी भारी समय-बरबादी और पीड़ा पैदा करते हैं। जो चीज़ें लोकप्रिय हैं, वे भी असल में basic tutorial स्तर से आगे जाते ही कई समस्याओं और कम productivity का कारण बनती हैं
यह developer skill level की बात ही नहीं है। आप कोई भी toolchain या product इस्तेमाल करें, अंत में आप किसी और की बनाई dependency ही इस्तेमाल कर रहे होते हैं। मेरे आस-पास बहुत कम लोग हैं जो matrix multiplication code खुद implement करते हैं, और वे भी अपने काम से असंबंधित open source libraries तक खुद नहीं लिखते। आम तौर पर लोग dependencies को लेकर तभी अटकते हैं जब regulatory requirements हों, निजी रुचि हो, या किसी खास library से लगाव हो। अगर हर कोई इस सिद्धांत को पूरी तरह लागू करे, तो हम सब समुद्र तट पर रेत बटोरते हुए जी रहे होते
"औसत CRUD developers मजबूत नहीं होते" वाली राय बहुत ज़्यादा sweeping है। अधिकांश developers यह चुन ही नहीं सकते कि वे किस system पर काम करेंगे, और development timeline में resources हमेशा कम होते हैं। 'सस्ती' dependencies का उपयोग करके ही काम करने वाला software जल्दी ship किया जा सकता है। यह बात शायद उस वास्तविकता को ठीक से समझे बिना कही गई लगती है
TigerBeetle अपेक्षाकृत हाल में लॉन्च हुआ startup है, और अभी 1.0 stable version भी नहीं आया। मुझे लगता है कि यह approach वास्तव में काम करती है या नहीं, यह कहने के लिए अभी बहुत जल्दी है
NIH(Not Invented Here) खुद में, अगर इसे इस यथार्थवादी समझ के साथ इस्तेमाल किया जाए कि आप कहाँ तक ज़िम्मेदारी लेना चाहते हैं, तो बहुत उपयोगी है। उदाहरण के लिए, मेरे domain के लिए बिल्कुल फिट web frontend framework को खुद बनाकर maintain करना कई बार काफ़ी worthwhile होता है। लेकिन database, game engine, web server, cryptography से जुड़ी मूल functionality जैसी चीज़ों में बात अलग है। अगर मौजूदा solutions से समस्या हल ही नहीं हो सकती क्योंकि कठिनाई बहुत ज़्यादा है, तो पहले समस्या को फिर से परिभाषित करने के बारे में सोचना चाहिए। SQLite की पूरी test suite को शुरुआत से दोबारा बनाने की बजाय, मुझे लगता है कि समस्या को नए सिरे से व्यवस्थित करना कहीं सस्ता पड़ेगा
Database, game engine, web server, crypto primitives जैसी चीज़ों में भी कई मामले ऐसे होते हैं जहाँ खुद बनाना बेहतर होता है। अगर simple files और runtime indexes ही काफ़ी हों, तो SQLite भी कई बार overkill होता है। बहुत-से games में, खासकर छोटी teams के लिए, custom engine फ़ायदेमंद हो सकता है। Ready-made engine का लाभ pipeline होता है, लेकिन उसके साथ बड़ा overhead आता है। Web server की complexity, FastCGI app से बहुत अलग नहीं होती। Cryptography में भी हर situation security issue नहीं होती, इसलिए simple hash verification जैसी चीज़ें खुद implement की जा सकती हैं। जो विषय कठिन लगते हैं, उनके प्रति learned helplessness रखना अच्छा नहीं है। यह भी महत्वपूर्ण है कि सिर्फ इसलिए कि कोई existing solution समस्या हल करता है, इसका मतलब यह नहीं कि वही सबसे optimal या सबसे efficient तरीका है
फिर इतने सारे database engines क्यों मौजूद हैं? अंततः जटिल computer systems में अपने-अपने trade-offs होते हैं। Constraints, scalability, concurrency, security, data characteristics, storage methods—चुनाव के आयाम बहुत विविध हैं। मेरा मानना है कि dependency की cost जितनी बड़ी हो, उतना ही भरोसा उस dependency पर होता है जो खुद अन्य dependencies को कम से कम रखने की कोशिश करती हो। Automated dependency management systems अक्सर समस्या को और जटिल बनाते हैं, इसलिए सावधानी से किया गया manual management बोझ कम कर सकता है
मैं third-party dependencies इस्तेमाल करने के दो कारण मानता हूँ। (1) जब service provider खुद उसे publish करता हो, और उसका lifecycle अपेक्षाकृत मेल खाता हो। (2) जब वह ऐसे जटिल code की जगह लेता हो जिसे मैं खुद लिखना नहीं चाहता। (1) में business कारण होते हैं, इसलिए समस्या नहीं। बस, service update होने पर बड़े बदलाव आएँगे यह मानकर चलना चाहिए। (2) का मूल्य इस बात पर निर्भर करता है कि मैं जिस code से बचना चाहता हूँ, उसकी complexity कितनी है। Dependency लाने का मतलब है कि दूसरे पक्ष के schedule के अनुसार मुझे update/test पर समय और resources खर्च करने होंगे, और वह ज़िम्मेदारी मुझे उठानी होगी
आपको ऐसे problems जल्दी मिल जाते हैं जिन्हें RDBMS से हल नहीं किया जा सकता। RDBMS concurrent data mutation और mutable datasets को केंद्र में रखकर बना होता है, इसलिए अगर आपको इसकी ज़रूरत नहीं है, तो simple indexing से भी बहुत बड़ा performance gain मिल सकता है। अगर data immutable है, तो RDBMS की तुलना में कहीं तेज़ custom implementation संभव है
RDBMS वाला उदाहरण रोचक है। Wikipedia में 100 से अधिक RDBMS सूचीबद्ध हैं, और हर एक की ऐसी problems हैं जिन्हें वह हल कर सकता है और ऐसी भी जिन्हें नहीं। यह practical solutions पर सोचने और उन्हें वास्तव में लागू करने का परिणाम है
Dependencies जोखिम पैदा करती हैं, लेकिन अगर बिल्कुल इस्तेमाल न करें तो development और time-to-market competitiveness में पिछड़ सकते हैं। इसलिए dependency management process महत्वपूर्ण है
बिंदु 4 और 5 वाकई बहुत महत्वपूर्ण हैं, लेकिन अक्सर भुला दिए जाते हैं। Personal projects में भी, कुछ समय छोड़कर लौटने पर मैंने dependencies को outdated या repo को deleted पाया है। इसलिए अब मैं source को private तौर पर fork करके खुद build करता हूँ, और dependencies की dependencies तक को source स्तर पर fork करके रखता हूँ। इससे बाद में ecosystem में अचानक बदलाव होने पर नुकसान कम किया जा सकता है। इसी वजह से binary से ज़्यादा source libraries पसंद आने लगी हैं
बिंदु 5 में fork करना कुछ ज़्यादा ही बोझिल हो सकता है। अपनी git या cache proxy में dependencies रखकर vendoring करना भी अच्छा तरीका है। खासकर long-lived projects के लिए यह ज़्यादा उपयुक्त है। NodeJS की तरह जब dependency files बहुत ज़्यादा हों, तब Yarn, PNPM जैसे tools ज़्यादा efficient हो सकते हैं
बिंदु 4 के संदर्भ में, SQLite जैसी प्रसिद्ध dependency मेरे बनाए product से कहीं ज़्यादा समय तक टिकेगी। अगर मैं मानूँ कि मेरा product उस open source project से भी ज़्यादा लंबा चलेगा, तो वह ज़्यादा अहंकारी रवैया होगा। Linux kernel को भी मैं खुद build करने की सोच नहीं रहा
कम-से-कम इतना तो होना ही चाहिए कि सारा code network connection के बिना build हो सके। Binary artifacts न हों तो सबसे अच्छा है, लेकिन यह हमेशा व्यावहारिक नहीं होता
शानदार insight है। मैं इसे अपने dependency adoption procedure document में जोड़ने वाला हूँ। समस्या JavaScript जैसी ecosystems में आती है जहाँ dependency tree बहुत गहरा होता है
लंबे अनुभव से मुझे लगता है कि अंत में हर चीज़ "It Depends™" ही होती है। जवान उम्र में मैं सिद्धांतों से चिपका रहता था और exceptions नहीं मानता था, और कई बार नतीजा यह हुआ कि अनुपयुक्त libraries या paradigms को ज़बरदस्ती लागू करके सबसे खराब code बना दिया। अब मैं जो चीज़ें बार-बार इस्तेमाल करता हूँ उन्हें खुद library बनाकर package के रूप में अलग रखता हूँ, और जिन चीज़ों की ज़रूरत है लेकिन जिन्हें मैं खुद नहीं कर सकता, केवल वही बाहर की dependencies से भरता हूँ। अगर quality और maintainability मुझे स्वीकार्य लगे, तो मैं external चीज़ें भी खुशी से अपनाता हूँ
Energy industry में dependencies को जानबूझकर टालने की प्रवृत्ति है। वजह यह है कि अगर आप external dependency लाते हैं, तो उसके सभी changes को देखना पड़ता है। AI code tools ने बहुत मदद की है, और मैं इन्हें मुख्यतः CLI tools बनाने में उपयोग करता हूँ। OpenAPI documentation भी LLM की मदद से बनाता हूँ, और फिर उसे Go standard library के साथ serve करता हूँ। LLM खुद एक external dependency है, लेकिन उससे बने CLI tools का actual code से सीधा संबंध नहीं होता, इसलिए quality requirement कम होती है। बेशक frontend developers React के बिना काम नहीं करना चाहेंगे, लेकिन ऐसे products को हम बाहर का मामला मानते हैं, इसलिए वह अपवाद है। अगर engineers को quality-critical dependencies के प्रति उनके जुनून से थोड़ा राहत देने वाले छोटे tools दिए जाएँ, तो dependency minimization policy लागू करना आसान हो जाता है
अच्छी और बुरी dependencies में फर्क कर पाना एक महत्वपूर्ण skill है। मेरे हिसाब से paid dependencies अक्सर नुकसानदेह होती हैं। संभव है कि उन्हें देने वाली company ने lock-in पैदा करने के इरादे से design किया हो। "dependency minimalism" एक अच्छा concept है (VitalikButerin का संबंधित tweet)
Paid dependencies में support का एक ही स्रोत होता है, इसलिए अगर वह company बंद हो जाए तो पूरा project जोखिम में पड़ जाता है। ज़्यादातर कंपनियाँ हमेशा नहीं चलतीं, इसलिए यह ज़रूर देखना चाहिए कि dependency का भविष्य आपके project की trajectory को कितना प्रभावित करेगा
मुझे non-technical background वाली टीम द्वारा थोपे गए paid dependency के साथ बुरा अनुभव रहा है। दूसरी ओर, Sidekiq जैसे community में व्यापक रूप से उपयोग होने वाले 'open-core' dependencies पर ज़्यादा भरोसा किया जा सकता है क्योंकि उनके अचानक गायब होने की संभावना कम है। Paid चीज़ों का फायदा यह है कि जब company स्वस्थ रूप से चल रही हो, तब support की चिंता कम रहती है
Company द्वारा दिए गए paid/free दोनों तरह के components में vendor lock-in मौजूद होता है। Risk management integration team की ज़िम्मेदारी है, और alternatives ढूँढकर या modularization करके risk को नियंत्रित करना चाहिए
अगर paid dependency है, तो lock-in रोकने के लिए उसे ज़रूर ऐसे interface के माध्यम से deliver किया जाना चाहिए जो open standard या alternative implementations की अनुमति देता हो। विकल्प बने रहें तो switch करने की गुंजाइश बची रहती है
Paid dependency को बुरा कहना इस बात का संकेत भी हो सकता है कि budget पर्याप्त नहीं है। मैं चाहता हूँ कि मेरे code को support करना किसी का 'job' हो। अगर supporters बहुत हैं या बहुत-से developers स्वेच्छा से ज़िम्मेदारी लेते हैं तो स्थिरता आती है, और personal project में भी, source खुला होने के बावजूद समस्या आने पर support देने वाला कोई होना चाहिए। Company बंद हो जाए तो भी चीज़ों को यूँ ही न छोड़ने की ज़िम्मेदारी महत्वपूर्ण है
बहुत-से लोग नया code लिखने को लेकर आसक्त रहते हैं, लेकिन वास्तविकता में 90% मामलों में एक खराब dependency का इस्तेमाल करना भी कहीं ज़्यादा efficient होता है
Dependency दोधारी तलवार है। बड़े software enterprises अक्सर code maintain करने की बजाय उसे फिर से लिखना सस्ता समझते हैं, इसलिए वैसा करते हैं। छोटी web/branding agencies में high-quality backend की असल में ज़्यादा ज़रूरत नहीं होती। दूसरी ओर, dreaded enterprise patterns के पैदा होने का एक कारण यह है कि 5 साल बाद भी, जब documentation और industry memory गायब हो जाए, तब code को external dependencies के बिना isolate और maintain किया जा सके। External dependencies में दो जोखिम निहित हैं: support बंद हो जाना, या breaking changes आना। अंततः इसका असर feature development flow पर पड़ता है। अगर components internal हों, तो इन trade-offs को भीतर ही नियंत्रित किया जा सकता है। अगर आप SaaS बना रहे हैं, तो short-term success के लिए dependencies जल्दी इस्तेमाल करना सही है, और अगर safety तथा long-term support अनिवार्य है, तो दूर की सोचने पर ही सफलता मिलेगी। नया code लिखना बहुत कम ही किसी organization का bottleneck होता है
मैं जानना चाहूँगा कि कंपनियाँ security vulnerabilities और licenses को कितनी गंभीरता से manage करती हैं। पहले मैं dependencies को लेकर उदार था, लेकिन security और license के प्रति सख़्त company में जाने के बाद मेरा नज़रिया बहुत बदल गया
Libraries और frameworks के अंतर को समझना भी महत्वपूर्ण है। Library एक ऐसा tool है जो एक काम अच्छे से करता है, जबकि framework पूरे app की संरचना तय करता है। Go community बड़े frameworks से दूरी रखती है और standard library, lightweight libraries, और ज़रूरत पड़े तो source copy/paste को पसंद करती है। उदाहरण के लिए Gin(web API), GORM(ORM) जैसे frameworks उपयोग में अच्छे हैं, लेकिन वे आंतरिक संरचना को सीमित करते हैं और complexity बढ़ाते हैं। Go का standard SDK खुद काफ़ी मजबूत है, इसलिए मुझे लगता है कि ज़रूरत से ज़्यादा dependencies जोड़ना ठीक नहीं
लेखक New Zealand से हैं। New Zealand की Number 8 wire spirit—यानी 'जो है और जितनी कारीगरी है, उसी से किसी तरह काम निकाल लेने' वाला रवैया—इस पृष्ठभूमि में मौजूद है (Number 8 wire wiki document)
New Zealand के बाहर के अनुभवी developers भी अक्सर इसी तरह सहमत होते हैं। गलत dependency चुनने या अनावश्यक library upgrades से परेशान होने का अनुभव लगभग सबको है
New Zealand से होने के नाते मुझे लगता है कि Number 8 Wire mentality शायद 20 साल पहले ही खत्म हो चुकी थी
आज पहली बार यह बात पता चली। इससे Australia की "She'll buff out, mate" कहावत याद आ गई
Dependency का बड़े पैमाने पर commercial आधार होना scalability को भी प्रभावित करता है। अगर कोई tool उन जगहों पर इस्तेमाल हुआ है जो मुझसे 100–1000 गुना बड़े scale पर deploy करते हैं, तो मेरे problem space में उसके limit से टकराने की संभावना कम होती है। उस scale पर bugs पहले ही मिल जाते हैं या ठीक हो जाते हैं, और नतीजतन वह मेरे लिए ज़्यादा सुरक्षित विकल्प बन जाता है
बड़ी libraries भी छोटे environments में बिल्कुल काम न करें, ऐसा हो सकता है। उदाहरण के लिए Swift protocol buffer compiler पहले unexpected fields पर crash हो जाता था। कई बड़ी कंपनियाँ अपने बड़े-scale use case के बाहर उन code paths को सीधे test भी नहीं करतीं
मैंने बड़ी कंपनियों(Meta, Google, Microsoft आदि) की बनाई प्रसिद्ध libraries में गंभीर bugs पाए हैं। Issue report करने पर भी उन्हें ठीक होने में बहुत समय लगता है, और बदलाव स्वीकारने में भी काफ़ी प्रतिरोध होता है। ऐसी स्थिति में अंततः मैंने खुद implement किया, और वह उल्टा तेज़ भी निकला और performance भी बेहतर हुई। खासकर consulting industry में, clients की अव्यावहारिक माँगों से काम की दिशा डगमगा जाती है। Developer के रूप में जब मेरा यह विश्वास बढ़ता है कि मैं खुद कर सकता हूँ, तो कई बार विशाल external dependency की बजाय खुद implement करना बेहतर लगता है। बेशक browser या AI model जैसी सचमुच बहुत बड़ी चीज़ें मैं नहीं बनाता, लेकिन जैसे local inference engine, HTML renderer, या मेरा खुद का graph database जैसी चीज़ें मैं खुद बनाता हूँ। Clients की अपेक्षा नई चीज़(innovation) नहीं बल्कि risk reduction होती है। जब मैं खुद develop करता हूँ, तो deadlines पूरा करना कहीं आसान होता है। Google या दूसरी बड़ी कंपनियों के docs खंगालने में समय बिताने से खुद बनाना ज़्यादा efficient लगता है। पिछले 3 महीनों से मैं 12-घंटे की शिफ्टों में देर रात तक उस project को बचाने में लगा हूँ जिसे पिछली team ने छोड़ दिया था, इसलिए इन बातों पर बहुत सोच रहा हूँ