Choose Boring Technology (2015)
एक व्यापक रूप से उद्धृत essay टीमों को “boring technology चुनने” की सलाह देता है और इस पर बहस छेड़ता है कि कब proven, well-understood stacks को उन नए tools के बजाय प्राथमिकता दी जाए जो अधिक payoff का वादा करते हैं लेकिन जोखिम भी बढ़ाते हैं। कई engineers “innovation tokens” जैसे विचारों की प्रशंसा करते हैं, क्योंकि यह novelty को सिस्टम के कुछ ही हिस्सों तक सीमित रखने का व्यावहारिक तरीका है, खासकर startups या infrastructure में जहाँ reliability, shared platforms, और maintainability, résumé-driven choices से अधिक महत्वपूर्ण होते हैं। अन्य लोग तर्क देते हैं कि “boring” जैसे labels अस्पष्ट होते हैं और उचित evaluation को रोक सकते हैं; उनका कहना है कि context, team expertise, evolving ecosystems (Node और Kubernetes से लेकर AI agents और LLM-friendly stacks तक), और स्पष्ट requirements को technology decisions चलाने चाहिए।
इनोवेशन टोकन और “बोरिंग” टेक
- कई टिप्पणीकार अभी भी “innovation tokens” वाले फ़्रेमिंग को गैर-इंजीनियरों को tradeoff समझाने और जोखिम को कुछ ही क्षेत्रों में केंद्रित रखने के तरीके के रूप में पसंद करते हैं।
- अन्य लोग तर्क देते हैं कि यह रूपक अस्पष्ट है; निर्णयों को “बोरिंग बनाम नया” के बजाय जोखिम, परीक्षण, failure modes, और टीम की विशेषज्ञता के संदर्भ में स्पष्ट रूप से फ़्रेम किया जाना चाहिए।
- कई लोग इस बात पर ज़ोर देते हैं कि “बोरिंग” संदर्भ-निर्भर है: अगर कोई टीम पहले से Node, Mongo, Rust आदि जानती है, तो वे उनके लिए बोरिंग माने जा सकते हैं।
“बोरिंग” की परिभाषा
- थ्रेड से निकली कार्यशील परिभाषा: ऐसी तकनीक जिसकी क्षमताएँ, और खासकर failure modes, अच्छी तरह समझे गए हों, और जिसमें “मुझे नहीं पता था कि यह ऐसा भी कर सकता है” जैसी बहुत कम आश्चर्यजनक बातें हों।
- आमतौर पर बोरिंग माने जाने वाले उदाहरण: Postgres/MySQL, PHP/Ruby/Django, cron, memcached, basic Linux + HAProxy stacks।
- कुछ लोगों का कहना है कि हर सिस्टम, यहाँ तक कि “बोरिंग” DBs भी, कई footguns रखते हैं; बोरिंग का मतलब बस “least bad known quantity” है।
Node, JavaScript, और ecosystem churn
- इस बात पर व्यापक सहमति है कि 2026 में Node स्वयं “बोरिंग” है, लेकिन कई लोग JS ecosystem (npm sprawl, tool churn, supply-chain risk) को अभी भी non-boring मानते हैं।
- इस पर बहस कि JS ecosystem में किसी चीज़ को mature कहा जा सकता है या नहीं, अन्य भाषाओं की तुलना में।
Kubernetes और infra complexity
- Kubernetes को बोरिंग मानने पर कड़ा विरोध है; कई लोग इसे अधिकांश कंपनियों के लिए overkill और outages तथा cognitive load का बड़ा स्रोत मानते हैं।
- Simple bare-metal या VPS setups, जिनमें छोटा stack हो (Linux + Postgres + PHP/Python), को अधिकांश business apps के लिए पर्याप्त बताया जाता है।
Incentives, careers, और “CV-driven development”
- कई टिप्पणियाँ नोट करती हैं कि resume incentives और hero culture flashy tech और firefighting को, prevention और boring reliability की तुलना में, अधिक reward करते हैं।
- अन्य लोग “CV-driven development” जैसे शब्दों को पसंद नहीं करते, क्योंकि उन्हें लगता है कि ये गलत motives अनुचित रूप से थोपते हैं।
AI/agents और boring tech
- कुछ लोग सुझाव देते हैं कि innovation tokens को AI/agents पर खर्च किया जाए और उन्हें in-distribution, boring stacks के साथ जोड़ा जाए जिन्हें models अच्छी तरह जानते हैं (जैसे Django, PHP, Go)।
- चिंता है कि LLMs लोकप्रिय या hyped stacks (TypeScript/Next.js) की ओर default करते हैं, जिससे विकल्प झुक जाते हैं।
- अन्य तर्क देते हैं कि LLMs वास्तव में पुराने, सरल tech का प्रभावी उपयोग करना आसान बनाते हैं।
थीसिस की आलोचनाएँ
- आलोचक कहते हैं कि “choose boring technology” एक thought-terminating cliché बन सकता है, जिसका उपयोग उचित innovation को रोकने या गलत legacy stacks को justify करने के लिए किया जाता है।
- वैकल्पिक सुझाव: हमेशा “सबसे उपयुक्त technology चुनें,” जहाँ boringness केवल requirements, workload fit, hiring, और ops cost के साथ एक factor हो।