जो सबसे सरल काम संभव हो, वही करें
(seangoedecke.com)- सॉफ्टवेयर डिज़ाइन में हमेशा “जो सबसे सरल काम संभव हो” उसे चुनना प्रभावी सलाह है
- बेहतरीन सिस्टम डिज़ाइन भव्य नहीं दिखता; वह वास्तव में न्यूनतम components का उपयोग करके समस्या हल करता है
- सरल समाधान अपनाते समय, केवल नई requirements आने पर ही धीरे-धीरे विस्तार करने के लिए YAGNI(You Aren't Gonna Need It) सिद्धांत को मुख्य डिज़ाइन दर्शन बनाया जा सकता है
- “सरलता” की परिभाषा पर बहस है, लेकिन कम components, ढीले internal connections और स्थिर system ही सरलता के सबसे करीब होते हैं
- अत्यधिक scalability पर ज़रूरत से ज़्यादा ज़ोर codebase को कम लचीला बना देता है, इसलिए वास्तविक requirements पर आधारित सरल डिज़ाइन लंबे समय में अधिक फायदेमंद होता है
जो सबसे सरल काम संभव हो, उसका पीछा
सॉफ्टवेयर system डिज़ाइन करते समय “जो सबसे सरल काम संभव हो” वही करना महत्वपूर्ण है। यह approach bug fix करने, मौजूदा system के maintenance, नई architecture डिज़ाइन करने जैसी लगभग हर स्थिति में लागू होती है। कई engineers एक “ideal” system का सपना देखते हैं—जो अच्छी तरह organized हो, लगभग अनंत तक scale कर सके, और साफ-सुथरे distributed structure में बना हो—लेकिन व्यवहार में मौजूदा system को गहराई से समझने के बाद सबसे आसान समाधान चुनना अधिक प्रभावी होता है।
सरलता का कम आकलन
- system डिज़ाइन के लिए app server, proxy, database, cache, queue जैसे कई tools इस्तेमाल करने की क्षमता चाहिए
- junior engineers अक्सर कई technologies का उपयोग करके जटिल structure बनाना चाहते हैं, लेकिन असली mastery अनावश्यक चीज़ों को हटाने में होती है
- बेहतरीन software डिज़ाइन फीका-सा दिखता है, बल्कि यह एहसास देता है कि समस्या को उम्मीद से अधिक आसानी से हल किया जा सकता है
- उदाहरण के लिए, Unicorn और Rails REST API Unix की बुनियादी क्षमताओं का उपयोग करके न्यूनतम structure में मुख्य guarantees (isolation, scaling, recovery आदि) हासिल करते हैं, इसलिए डिज़ाइन के लिहाज़ से उत्कृष्ट हैं
सरल तरीके से implement करने की सोच
- उदाहरण के लिए, किसी Golang application में rate limiting जोड़ते समय Redis जैसे external storage का उपयोग किया जा सकता है, लेकिन अगर वह अनिवार्य न हो तो पहले in-memory count जैसे सरल तरीकों को आज़माया जा सकता है
- अगर सरल तरीका पर्याप्त हो, तो भारी infrastructure जोड़ने को टाला जा सकता है
- वास्तव में नई requirements आने पर ही system को विस्तार देने वाला incremental development rollout संभव हो जाता है
- यह डिज़ाइन में YAGNI सिद्धांत को सर्वोच्च प्राथमिकता देने वाला approach है
सरलता के जाल और व्यावहारिक सीमाएँ
1. Big Ball of Mud घटना
- अगर हर requirement को तुरंत निपटाते जाएँ, तो codebase एक जटिल और maintain करना कठिन “big ball of mud” में बदलने का जोखिम रखता है
- लेकिन ad-hoc hack सरलता नहीं है; वह समझने और maintain करने में और ज़्यादा जटिलता पैदा करता है
- सचमुच सरल समाधान खोजने के लिए कई तरीकों की तुलना करनी पड़ती है और वास्तव में systematic engineering करनी होती है
2. सरलता की परिभाषा
- “सरलता” क्या है, इस पर सहमति बनाना आसान नहीं है
- आम तौर पर सरल system में moving parts (कार्यरत तत्व) कम होते हैं, components के बीच ढीला coupling होता है, और interfaces स्पष्ट होते हैं
- वास्तविक उदाहरण: Unix process और Unicorn memory share नहीं करते, इसलिए उनकी सरलता अधिक है; Puma या Redis की तुलना में उनकी internal connectivity भी कम है
- जब विकल्प स्पष्ट न हो, तो जिसे कम maintenance चाहिए वही अधिक सरल माना जा सकता है
3. scalability के प्रति आसक्ति की आलोचना
- “सरल तरीका” बड़े पैमाने के traffic के लिए उपयुक्त न भी हो सकता है
- लेकिन भविष्य में अचानक scale बढ़ने की आशंका के लिए पहले से जटिल डिज़ाइन बनाना आमतौर पर बेकार प्रयास होता है
- अधिकांश code को वास्तव में केवल 2–5 गुना तक बढ़ने वाले traffic के लिए तैयार रहना होता है; उससे आगे की स्थिति में समस्या आने पर प्रतिक्रिया देना अधिक तर्कसंगत है
- अत्यधिक scalability-केंद्रित डिज़ाइन code की flexibility को नुकसान पहुँचाता है; ज़रूरत से ज़्यादा structural विभाजन किसी खास feature को implement करना उल्टा कठिन बना सकता है, और जटिल transaction management की मांग भी कर सकता है
निष्कर्ष
- समय के साथ system की भविष्य की requirements का अनुमान लगाने की क्षमता को लेकर निराशावाद बढ़ता है
- व्यवहारिक दुनिया में मौजूदा system की स्थिति को सही-सही समझना ही काफी कठिन है, और यही अच्छी डिज़ाइन में सबसे बड़ी बाधा है
- software development में मोटे तौर पर दो तरीके होते हैं
- भविष्य की requirements का अनुमान लगाकर डिज़ाइन करना
- वर्तमान requirements के प्रति ईमानदार रहकर जो सबसे सरल काम संभव हो उसे बार-बार करना
- दूसरा तरीका व्यवहार में अधिक प्रभावी है, और YAGNI तथा सरलता-केंद्रित सोच लंबे समय में बेहतर डिज़ाइन बनाती है
परिशिष्ट: Hacker News चर्चा और शब्द के स्रोत
- इस राय के जवाब में कि architecture की सरलता scale बढ़ने पर अर्थहीन हो जाती है, लेखक का तर्क है कि बड़े scale पर भी सरल structure और अधिक महत्वपूर्ण हो जाता है (features के बीच interaction की जटिलता के कारण)
- “Do the simplest thing that could possibly work” वाक्यांश Ward Cunningham और Kent Beck ने गढ़ा था
1 टिप्पणियां
Hacker News राय
मेरा मानना है कि ऐसा अप्रोच सरल डोमेन में अच्छी तरह काम कर सकता है। लेकिन बड़ी टेक कंपनियों में लंबे समय तक काम करने के बाद भी, जो जटिलता वास्तव में चाहिए होती है वह हमेशा चौंकाती है। सबसे सरल बिज़नेस समस्या को भी हल होने में एक साल से ज़्यादा लग जाता है, या फिर अनगिनत edge cases और scale समस्याओं की वजह से बार-बार टूट जाती है। जो लोग सादगी की बात करते हैं, उनके पास शायद बड़े पैमाने का अनुभव नहीं रहा होगा। 10 साल पुराने codebase को देखकर भी लगता है कि ध्यान रखने वाली चीज़ें इतनी ज़्यादा हैं कि rewrite भी अक्सर असफल हो जाता है। Chesterton's Fence वाली उपमा की तरह, अगर किसी चीज़ के होने की वजह पता न हो तो उसे यूँ ही हटाना नहीं चाहिए—ऐसी समझदारी ज़रूरी है
मुझे लगता है यह software engineers के बीच communication की कमी से पैदा हुआ एक क्लासिक misunderstanding है। बात यह है कि लेख के शीर्षक की तरह, "जो संभव हो उसमें सबसे सरल चीज़" करो। जटिल समस्याओं में कुछ जटिलता अपरिहार्य है, लेकिन मतलब यह है कि उसे अनावश्यक रूप से और जटिल बनाने की गलती से बचो। यह नहीं कहा जा रहा कि complexity को पूरी तरह टाल दो, बल्कि यह कि उसे जरूरत से ज़्यादा बढ़ाने की आदत से सावधान रहना चाहिए
जैसा बताया गया, जटिलता का कारण हमेशा डोमेन खुद नहीं भी हो सकता। यह खराब software design का परिणाम हो सकता है। अगर सब कुछ dependencies और side effects से भरा है, तो इसका मतलब है separation of concerns और coupling management सही से नहीं हुआ। तब refactoring लगभग असंभव हो जाती है, और अगर संगठन की संस्कृति नहीं सुधरती तो refactor के दौरान नई समस्याएँ ही परत-दर-परत जुड़ती जाती हैं। फिर भी separation of concerns और simple composition भर से भी जटिल समस्याएँ हल की जा सकती हैं। यह कठिन है, लेकिन senior developers के पास यह दृष्टिकोण मज़बूती से होना चाहिए, तभी सफलता की संभावना बढ़ती है
लेखक के GitHub में staff engineer होने का ज़िक्र देखकर लगता है कि इस व्यक्ति के पास बड़े पैमाने के systems का पर्याप्त अनुभव है
legacy systems edge पर मौजूद होते हैं। वास्तविक systems में भी, जैसे बहु-आयामी space में dimensions बढ़ने पर points boundary surfaces यानी edges की तरफ इकट्ठे होते हैं, वैसे ही असली users भी अक्सर system की सीमाओं के पास काम करते हैं। इन सभी edges को सबसे बेहतर तरीके से संभालने वाली चीज़ आखिरकार पुरानी existing system ही होती है
मेरी पिछली नौकरी में जटिलता का एक बड़ा हिस्सा failed, छोड़ी गई, या अधूरी refactoring और improvement कोशिशों से आया था। मैं अक्सर सोचता था कि अगर इन्हें शुरुआत में रोका गया होता, तो क्या हमें ज़्यादा सरल system मिलता। इसका मतलब यह नहीं कि refactor और improvement बिल्कुल न किए जाएँ, बल्कि यह कि योजना ऐसी हो जो 100% use cases को कवर करे, budget और milestones पहले से सुरक्षित हों, और फिर क्रमिक सुधार सुनिश्चित किए जाएँ
काश "जो संभव हो उसमें सबसे सरल चीज़" इस अभिव्यक्ति की उत्पत्ति का ज़िक्र ज़रूर किया गया होता। यह वाक्य wiki के आविष्कारक Ward Cunningham और Kent Beck के साथ काम करते समय 80 के दशक के आखिर में अक्सर इस्तेमाल किया जाने वाला सिद्धांत था। दोनों coding करते समय एक-दूसरे को यह सिद्धांत लगातार याद दिलाते थे, और बाद में presentations और writing में भी यह एक महत्वपूर्ण विषय बन गया। बंद दरवाज़े वाले उदाहरण की तरह, यह लेख भी बताता है कि कुछ सरल दिखने वाली चीज़ का "सरल" होना परिस्थिति पर निर्भर करता है। यानी सरल समाधान ढूँढना हमेशा सरल नहीं होता। इस तरीके में technical debt छोड़ देने का जोखिम होने की समझ भी थी, लेकिन पहले code को काम कराने को प्राथमिकता दी जाती थी। निजी तौर पर मुझे लगता है कि इस लेख में technical debt वाले पहलू पर थोड़ा और होना चाहिए था
Kent Beck ने बाद में Extreme Programming को औपचारिक रूप दिया। यह methodology ऐसी practices का संग्रह है जो requirements बदलने पर simple systems को स्वाभाविक रूप से evolve होने में मदद करती है
मैंने यह अभिव्यक्ति अपने एक सहकर्मी से सुनी थी और जाना कि वह इसे जीवन-मंत्र की तरह इस्तेमाल करता है, लेकिन मुझे नहीं पता था कि इसका मूल Ward Cunningham हैं। यह वाक्य इतना व्यापक हो गया है कि शायद इसके मूल रचयिता को कोई न जानना ही सबसे बड़ा सम्मान है
Wiki का ज़िक्र दिलचस्प लगा। मेरी पुरानी नौकरी में project management के लिए Lotus Notes इस्तेमाल होता था, और वह यह highlight कर देता था कि कौन-से documents कब बदले गए, इसलिए उपयोगी था। उसके बाद वाले project में हमने सिर्फ Wiki इस्तेमाल किया, लेकिन कौन-सा document बदला है यह एक नज़र में पता नहीं चलता था, इसलिए वह व्यावहारिक रूप से बेकार हो गया। वह सरल तो था, लेकिन इतना अधिक सरल कि उपयोगिता ही घट गई
"काम करता है" की परिभाषा को लेकर अपने पूरे करियर में सबसे ज़्यादा बहस देखी है। "यह काम करता है, इसका मतलब यह नहीं कि यह टूटा नहीं है"—यह बात उन लोगों को सहज रूप से समझ आती है जिन्होंने खुद कुछ ठीक किया हो। मरम्मत करने वाले लोग टूटे औज़ार से काम चलाते-चलाते अंत में उसे बदलने का फैसला कर लेते हैं, लेकिन developers को अक्सर "इसे सच में ठीक करना चाहिए" वाली ज़रूरत उतनी तीव्रता से महसूस नहीं होती
मेरे करियर का सबसे कठिन दौर वह था जब मैं ऐसी कंपनी में था जहाँ एक team prototypes बनाना पसंद करती थी। वह team बहुत तेज़ी से proof of concept बनाती, executives को demo दिखाती, और तुरंत deploy करने की बात करती। फिर executives यह मान लेते कि अगर यह इतना जल्दी "पूरा" हो गया, तो इसे तुरंत production में भी डाला जा सकता है। बाद में जिम्मेदार team जब code खोलती, तो पता चलता कि end-to-end security, validation, error handling जैसी अनिवार्य चीज़ें सब गायब हैं। आखिरकार सब कुछ शुरुआत से फिर बनाना पड़ता, और executives यह गलत समझते कि delivery team बेवजह चीज़ों को जटिल बना रही है
मैंने कहीं एक प्रभावशाली उद्धरण पढ़ा था: "किसी program का काम करना पर्याप्त नहीं है। उसे सही कारणों से काम करना चाहिए।" मूल रूप से संदेश वही है
ऐसी बातचीत पेशेवर रूप से बहुत महत्वपूर्ण है। कोई system इच्छित output दे सकता है, इस अर्थ में वह "काम करता है", लेकिन reliability या cost के नज़रिए से फिर भी उसे विफल माना जा सकता है
मेरे काम में "काम करता है" की परिभाषा इस पर निर्भर करती है कि employer resources—यानी मेरे समय—को कहाँ लगाना चाहता है। अगर quality सुधारने के लिए समय दिया जाता है, तो मैं पूरी कोशिश करता हूँ। उल्टा अगर सिर्फ targets पूरे करने या checklist टिक करने की अपेक्षा हो, तो उसी हिसाब से काम करता हूँ। मेरा मानना है कि जो चीज़ मापी जाती है, अंततः वही परिणाम देती है; मैं सलाह दे सकता हूँ, लेकिन अंतिम निर्णय मेरे हाथ में नहीं होता
ऐसे सुझावों की विडंबना यह है कि इन्हें सही तरीके से लागू वही लोग कर पाते हैं जो पहले से अनुभवी विशेषज्ञ हों। उदाहरण के लिए, आप कैसे जानेंगे कि "सबसे सरल चीज़" क्या है, और कैसे तय करेंगे कि वह सच में चलेगी। हाल ही में मुझे अपने बनाए XLSX importer में XML namespace handling की गलती झेलनी पड़ी, क्योंकि मैंने मान लिया था कि Excel हमेशा default namespace ही इस्तेमाल करेगा। बाद में namespace अलग वाली file मिली और सब तुरंत टूट गया। सिर्फ prefixes हटाकर पार्स करना आसान होता, लेकिन अपने भविष्य के लिए मैंने 4 घंटे लगाकर पूरे parser को namespace-friendly तरीके से फिर से लिखा। "सबसे सरल चीज़" करना व्यवहार में इतना आसान नहीं है, और अनुभव बढ़ने पर इसका फैसला थोड़ा बेहतर हो सकता है। लेकिन जब आपके पास उस स्तर का अनुभव आ जाता है, तब शायद ऐसे सलाह की ज़रूरत भी कम रह जाती है
मुझे लगता है कि लेख के मुख्य भाग में भी बताया गया था कि यह सलाह लागू करना कठिन क्यों है। मुख्य बात यही है कि "सबसे सरल समाधान खोजने के लिए कई approaches पर विचार करना पड़ता है, और अंततः engineering mindset चाहिए"
हमारे यहाँ कंपनी में एक सिद्धांत है: "कोड को गलत दिशा में मत बढ़ाओ।" implementation अधूरी हो तो भी coding उसी दिशा में करो जो आगे विकसित करना आसान बनाए। यह KISS है, लेकिन shortcuts की बिल्कुल अनुमति नहीं है
मैं simplicity को "जिसे transition करना सबसे आसान हो" इस कसौटी से देखता हूँ। किसी जटिल abstraction या infrastructure पर निर्भर न रहने वाली single service आखिरकार transition के लिए सबसे आसान होती है। पढ़ने वाला उसे तुरंत समझ सकता है, handover और debugging भी आसान होती है। हाँ, abstraction की जरूरत हो तो ज़रूर जोड़ो, और infrastructure सचमुच चाहिए हो तो उसे भी जोड़ो। मुख्य बात यह है कि code सौंपते समय क्या यह सबसे आसान समझाने योग्य संरचना है—मैं हमेशा यह सोचता हूँ। पहले मैं सब कुछ abstracted / service-wise separated / configuration-driven बनाने की कोशिश करता था ताकि code लगभग न के बराबर रहे, लेकिन व्यवहार में transition और handover पूरी तरह विफल रहे। अब मैं structure को तभी जटिल बनाता हूँ जब सच में ज़रूरत हो, और डिफ़ॉल्ट रूप से intuitive simplicity बनाए रखता हूँ। इससे नए लोगों की onboarding, bug fixing और वास्तविक transition—सबमें फायदा होता है
AI vibecoding भी कुछ ऐसा ही है। अनुभव और know-how बढ़ने के साथ उपयुक्त tasks चुनना और agents को manage करना आसान होता जाता है
बहुत लोग यह चूक जाते हैं कि "सबसे सरल चीज़" का मतलब shortcut या जल्दबाज़ी में किया गया patchwork नहीं है। जितनी सरल विधि होती है, उतना ही अधिक विचार और system understanding अक्सर चाहिए होती है; लेख की शुरुआत भी इसी बात पर थी। लगता है कई लोगों ने सिर्फ शीर्षक पढ़कर अपनी भड़ास निकाल दी
आम तौर पर, जैसे ही मैं ऐसे किसी सिद्धांत या बहुत मजबूत दावे को सुनता हूँ, मेरे भीतर सतर्कता आ जाती है। अगर कोई software development के बारे में ऐसे बोले मानो कोई सार्वभौमिक सही उत्तर हो, तो अक्सर वह उतना नहीं जानता। सचमुच अनुभवी developer का निष्कर्ष यह होता है कि software कठिन है और सावधानी माँगता है। कोई जादुई universal answer नहीं है। खुली सोच और संवेदनशीलता ज़रूरी है
simplicity—यानी complexity का उल्टा—software design alternatives की तुलना करते समय लगभग सबसे महत्वपूर्ण मानदंड है। वजह साफ़ है: अंत में इंसानों को ही plan करना, सहमत होना, implement करना और maintain करना पड़ता है। लेकिन simplicity का आकलन करना बेहद कठिन है, और उद्योग के औसत engineer के निर्णय पर इसमें भरोसा करना मुश्किल है। ऊपर से, "simplicity" का दावा खुद एक लगभग अर्थहीन buzzword बनकर फैल गया है, और कई बार किसी ठोस तर्क का जवाब सिर्फ "यह ज़्यादा simple है" कहकर दिया जाता है। ideal रूप में team lead को ऐसे मुद्दों को सही से पहचानना चाहिए, लेकिन team leads की क्षमता पर भरोसा करना दिन-ब-दिन कठिन होता जा रहा है, इसलिए यह और मुश्किल हो गया है
लेख में एक प्रभावशाली पंक्ति भी थी। सच्चा उस्ताद यह जानता है कि क्या जोड़ना नहीं है; नवशिक्षु बहुत हरकतें और चमक-दमक दिखाता है, जबकि उस्ताद कम चलता है और सिर्फ निर्णायक वार करता है
लेख पढ़ते समय शुरुआत में मुझे थोड़ी चिढ़ भी हुई थी, लेकिन मुझे लगता है कि इसने trial and error के मूल स्वभाव को ठीक पकड़ा: "shortcut" अंततः एक और complexity ही जोड़ता है। समस्या तब होती है जब ऐसे सिद्धांतों को management आदेश की तरह अतिरेक में लागू किया जाता है, और जटिल समस्या का बहुत सरल जवाब देने की कोशिश में knowledge transfer भी कठिन हो जाता है और बाद में और ज़्यादा जटिल cleanup बचता है। दूसरी तरफ, चीज़ें जरूरत से ज़्यादा complex इसलिए भी हो जाती हैं कि हम लगातार improvisation और shortcuts के बोझ तले रहते हैं, फिर एक बार में सब ठीक करने जाते हैं और इस बार जरूरत से ज़्यादा कर बैठते हैं। अंततः developers को बैठकों में सक्रिय रूप से हस्तक्षेप करके शुरुआत से ही समझदार निर्णयों की दिशा बनानी चाहिए
मुझे नहीं लगता कि यह इतना गंभीर red flag है। अनावश्यक complexity हर दिन बढ़ती रहती है, इसलिए simplicity बचाए रखने की वकालत करना जरूरी है। designers, product managers, यहाँ तक कि customers और architects भी सहज रूप से complexity जोड़ने की तरफ झुकते हैं
मैं तुम्हारी बात से सहमत हूँ, लेकिन यह भी ध्यान देने लायक है कि आखिरकार बात "everything is a trade-off" या "there is no free lunch" पर आकर टिकती है। कोई भी general principle असल में field experience का निचोड़ होता है, इसलिए उसे पूरी तरह हटाया नहीं जा सकता। समस्या तब होती है जब कोई उपयोगी concept किसी समय अत्यधिक प्रचार या धर्म जैसा रूप ले लेता है और फिर बस folder names पर बहस बचती है
Startup (Seed~Series C) माहौल में कई 0-1 systems बनाते हुए मैंने एक सिद्धांत आत्मसात किया है: "simplicity ही robustness है।" शुरुआती design हो या existing system में सुधार—बहुत आसानी से over-engineering हो जाती है। ग्राहक की ज़रूरतें लगातार बदलती रहती हैं, और भविष्य की requirements का अनुमान लगाएँ भी तो वह अक्सर गलत निकलता है। मुझे लगता है simplicity सिर्फ errors कम नहीं करती, बल्कि structure को आसानी से बदल पाने की नींव भी देती है। X, Y, Z जैसी संभावनाओं के लिए तैयार रहो, लेकिन future extensibility और breathing room देने के लिए दिशा "सबसे सरल चीज़" बनाने की होनी चाहिए। complexity अनिवार्य रूप से constraints बढ़ाती है, और समय के साथ जितनी जमती जाती है, stack उतना ही कमज़ोर होता जाता है
मेरा मानना है कि "ideal system" design करने की कुछ कोशिशें करने के बाद ही अंततः इंसान "सबसे सरल चीज़" तक पहुँच पाता है। पढ़ने में आसान और बदलाव के लिए अनुकूल system बनाना भी बहुत गहरे know-how की माँग करता है। सचमुच "सरल" सुधार भी अनुभव और गहरी समझ से ही आता है
यह Gall's law के ही संदर्भ में है। इस सिद्धांत के अनुसार, जो complex system ठीक से काम करता है वह हमेशा किसी simple system से शुरू हुआ होता है और फिर धीरे-धीरे complexity जुड़ी होती है। जो system शुरुआत से ही complex बनाया जाता है, वह अक्सर सफल नहीं होता। इसलिए पहले सबसे simple system बनाना चाहिए, और फिर requirements के मुताबिक धीरे-धीरे complexity जोड़नी चाहिए
मैं लेख की भावना से सहमत हूँ, लेकिन मुझे लगता है कि cloud infrastructure के आने से "simplicity" की परिभाषा बदल गई है। पहले बात कुछ ऐसी थी: "simple लेकिन scalable नहीं" बनाम "complex लेकिन scalable"। अब स्थिति वैसी नहीं है। in-memory rate-limiting solution single server पर simple लग सकती है, लेकिन दो server होते ही distributed state की समस्या बन जाती है। दूसरी तरफ DynamoDB या ElastiCache जैसी managed services single node हो या 1000 machines, एक single source of truth देकर complexity बहुत घटा सकती हैं। अगर "simple systems are robust" वाले नज़रिए से देखें, तो managed services का उपयोग करना अधिक बुनियादी अर्थ में simple कहा जा सकता है, क्योंकि वे data loss, distributed state management जैसी दोहराई जाने वाली समस्याओं को हटा देती हैं। अब "सबसे सरल चीज़" की परिभाषा शायद इस दिशा में बदल गई है कि आप no-ops managed services का समझदारी से उपयोग करें। आजकल बाहरी dependencies से बचने की तुलना में, अच्छी तरह isolate और validate किए गए systems का leverage लेकर complexity घटाना ही समय और लागत दोनों बचाता है
मैं इस कथन से सहमत हूँ: "जितना संभव हो उतना सरल बनाओ, लेकिन उससे भी कम सरल मत बनाओ।" मैं हमेशा इस सिद्धांत का पालन करने की कोशिश करता हूँ, लेकिन अक्सर सोचता हूँ कि कहीं मैं नई technologies को ठीक से न जानने के कारण अनावश्यक complexity को पहचानने से चूक तो नहीं रहा, या फिर बाकी सब लोग सच में बेवजह complexity में फँसे हुए हैं। किसी tool का असली उपयोग समझना बिना उसे वास्तविक project में इस्तेमाल किए मुश्किल है, लेकिन दूसरी तरफ सिर्फ अपनी learning के लिए नए tools को production में ठूँस देना team के लिए नुकसानदेह हो सकता है—यह भी मैंने देखा है
मैं भी इसी तरह के दुःस्वप्न से गुजर रहा हूँ। हमारे यहाँ ऊपर के लोग हमेशा नवीनतम software में रुचि रखते हैं, इसलिए मुझे ऐसे tools को production में evaluate करना पड़ता है जिनका महत्व संदिग्ध है। business results से संबंध न होते हुए भी हर हफ्ते ऐसी exploration करते रहने का दबाव है
व्यवहार में मुझे लगता है कि पहले सबसे आसान तरीके से चीज़ को चलाकर देखना चाहिए—ज़रूरत पड़े तो manually भी—और पूरी functionality तभी जोड़नी चाहिए जब उसकी सच में ज़रूरत सामने आए। अगर शुरुआत में सब कुछ automate/toolify करके समय भी बर्बाद किया हो, तब भी बाद में यह साफ़ समझ आ जाना कि उसकी ज़रूरत क्यों है, वही अनुभव अधिक मूल्यवान है
यह भावना मुझे बहुत परिचित लगती है। मैं भी ऐसे लेखों से हमेशा सहमत होता हूँ और simplicity अपनाने की कोशिश करता हूँ, लेकिन हमेशा भ्रम रहता है कि क्या यह सचमुच समझदारी और व्यावहारिकता है, या सिर्फ अनुभव/कौशल की कमी
इसी वजह से मैं बहुत सावधान रहता हूँ कि कहीं यह "résumé-driven development" में न बदल जाए