- सरल तरीकों को पेपर समीक्षा या प्रमोशन मूल्यांकन में कम आंका जाने के पीछे complexity bias काम करता है, क्योंकि जटिल परिणामों में अधिक मेहनत, कौशल और innovation दिखाई देता है
- जिन सिस्टमों में विकल्प और components ज़्यादा होते हैं, वे लचीले लग सकते हैं, लेकिन वास्तविक संचालन में उन्हें समझाना, test करना और troubleshoot करना कठिन हो जाता है, और गलतियाँ व inefficiency बढ़ सकती हैं
- सरल ideas और systems को समझना, इस्तेमाल करना, feedback लेना और scale करना आसान होता है; 2012 के acquisition के समय Instagram ने 13 लोगों की टीम के साथ करोड़ों users को सेवा देते हुए PostgreSQL aur Redis जैसी proven technologies को बनाए रखा
- machine learning में भी जटिल techniques हमेशा बेहतर नहीं होतीं; मध्यम आकार के 45 tabular datasets पर tree-based models ने deep neural networks से बेहतर प्रदर्शन किया, और recommendation/search में dot product के neural collaborative filtering से बेहतर होने के उदाहरण हैं
- अगर जटिलता को ही reward किया जाए, तो अनावश्यक complexification और not invented here प्रवृत्ति बढ़ती है; इसलिए समस्या जितनी जटिल हो, पहले यह देखना चाहिए कि क्या सरल समाधान संभव है और क्या जटिलता की लागत उचित है
जटिलता अधिक आकर्षक क्यों दिखती है
- जटिलता को मेहनत के संकेत के रूप में लेना आसान होता है
- कठिन ideas और तकनीकी details से भरे papers ऐसे लगते हैं जैसे उनमें बहुत समय और मेहनत लगी हो
- जिन systems में components और features अधिक होते हैं, उन्हें छोटे systems की तुलना में अधिक मेहनत से बनाया गया output मान लिया जाता है
- इसे बनाना मुश्किल है, यह धारणा ही value और quality के संकेत की तरह काम करने लगती है
- इसे कौशल के संकेत के रूप में भी पढ़ा जाता है
- कई moving parts वाले systems यह impression देते हैं कि designer हर हिस्से को समझकर integrate कर सकता है
- terminology और proofs से भरे papers तक पहुँचना मुश्किल होता है, लेकिन इसी वजह से वे विषय-विशेषज्ञता दिखाते हुए लगते हैं
- interviews में ऐसे algorithms और data structures पूछने की परंपरा, जो व्यवहार में लगभग कभी उपयोग नहीं होते, भी इसी signaling से जुड़ी है
- इसे innovation के संकेत की तरह भी देखा जाता है
- पूरी तरह नई model architecture बनाने वाला paper, मौजूदा network में बदलाव करने वाले paper से अधिक नया माना जाता है
- scratch से बनाए गए अधिक components वाला system, existing parts को reuse करने वाले system से अधिक मौलिक दिखता है
- “सिर्फ़ एक चीज़ बदली है और बाकी सब existing research जैसा है” जैसी टिप्पणी सरल ideas की value घटा सकती है
- features जितने अधिक हों, उतना अधिक comprehensive होने का भ्रम पैदा होता है
- जो system SQL और NoSQL दोनों data stores को support करता हो, या batch और streaming pipelines दोनों को संभव बनाता हो, वह ऐसा लगता है जैसे हर case को संभाल लेगा
- जितने अधिक Lego blocks, उतनी अधिक बदलावों के प्रति adaptability मानी जाती है
- ऐसा आकलन सरल ideas और systems की तुलना में जटिल चीज़ों को ज़रूरत से ज़्यादा पसंद करने वाले complexity bias में बदल जाता है
जहाँ सादगी वास्तव में फ़ायदा बनती है
- सरल ideas और features को समझना और उपयोग करना आसान होता है
- adoption की संभावना और वास्तविक impact बढ़ता है
- communicate करना और feedback लेना भी आसान होता है
- जटिल systems को समझाना और manage करना कठिन होता है, इसलिए users के लिए यह समझना मुश्किल हो जाता है कि क्या और कैसे करना है
- अगर tune करने के लिए बहुत ज़्यादा चीज़ें हों तो गलतियाँ बढ़ती हैं, और अगर steps बहुत ज़्यादा हों तो inefficiency पैदा होती है
- सरल systems बनाना और scale करना आसान होता है
- components कम हों तो implementation आसान हो जाती है
- standardized off-the-shelf technologies का उपयोग करें तो implementation और maintenance करने वाले लोगों को ढूँढना आसान होता है
- code और internal interactions कम होने से समझने और testing का बोझ भी घटता है
- अनावश्यक रूप से जटिल systems निर्माण में अधिक समय और resources लगवाते हैं, जिससे बर्बादी होती है
- Instagram का उदाहरण सरल तकनीकी चुनावों के फ़ायदे दिखाता है
- 2012 के acquisition के समय Instagram 13 लोगों की टीम के साथ करोड़ों users को सेवा दे रहा था
- नई fashionable technologies के बजाय proven technologies बनाए रखकर उसने प्रति engineer operational burden कम रखा
- जब अन्य startups लोकप्रिय NoSQL data stores अपनाकर मुश्किलों का सामना कर रहे थे, तब Instagram ने समझने में आसान PostgreSQL aur Redis का उपयोग किया
संचालन लागत और maintainability
- system deployment अंत नहीं, बल्कि शुरुआत है
- अधिकांश मेहनत production में जाने के बाद आती है
- operation की ज़िम्मेदारी अक्सर मूल टीम के बजाय किसी और के पास जाती है
- सरल systems maintenance cost कम कर सकते हैं और lifespan बढ़ा सकते हैं
- moving parts जितने कम हों, system उतना अधिक reliable और fix करना आसान होता है
- failure के संभावित हिस्से कम हो जाते हैं
- internal interactions कम होने से individual components को upgrade या replace करना आसान होता है
- जटिल systems में ऐसे components अधिक होते हैं जिन्हें सीमित टीम को समझना पड़ता है, इसलिए maintenance cost बढ़ती है
- interdependent parts ज़्यादा हों तो troubleshooting और भी कठिन हो जाती है
- Thomas Paine ने Common Sense में लिखा था: “कोई भी चीज़ जितनी अधिक सरल होती है, उसके बिगड़ने की संभावना उतनी कम होती है, और बिगड़ने पर उसे ठीक करना उतना आसान होता है”
ऐसे मामले जहाँ machine learning में भी सरल techniques पीछे नहीं रहतीं
- अधिक sophisticated techniques हमेशा बेहतर performance नहीं देतीं
- Tree-based models > deep neural networks: मध्यम आकार के 45 tabular datasets पर tree-based models, deep neural networks से बेहतर रहे
- Greedy algorithms > graph neural networks: combinatorial graph problems में greedy algorithms, graph neural network से बेहतर रहे
- Simple averaging ≥ complex optimizers: multi-task learning problems में simple averaging, complex optimizers से कमतर नहीं था
- Simple methods > complex methods: 32 papers में prediction accuracy के स्तर पर simple methods, complex methods से बेहतर रहे
- Dot product > neural collaborative filtering: item recommendation और search में dot product, neural collaborative filtering से बेहतर रहा
जटिलता को reward करने पर पैदा होने वाली समस्याएँ
- अगर जटिलता को reward किया जाए, तो लोग अनावश्यक रूप से जटिल चीज़ें बनाने के लिए incentivized हो जाते हैं
- simple methods या systems सिर्फ़ आसान दिखने के कारण कम मूल्यवान माने जा सकते हैं
- reward पाने के लिए system को जटिल बनाना, सबसे सरल समाधान को स्पष्ट विकल्प नहीं रहने देता
- जटिलता और अधिक जटिलता को जन्म देती है, और अंततः काम को असंभव स्तर तक पहुँचा सकती है
- not invented here प्रवृत्ति भी मज़बूत होती है
- existing components को reuse करने से समय और मेहनत बच सकती है, फिर भी scratch से बनाने की प्रवृत्ति बन जाती है
- इससे समय और resources की बर्बादी हो सकती है और नतीजे भी बदतर हो सकते हैं
- प्रमोशन प्रक्रियाओं और machine learning paper reviews में भी जटिलता पर ज़रूरत से ज़्यादा ज़ोर दिया जा सकता है
- Bryan Liles का कहना है कि simple solutions को implement और scale करना complex solutions की तुलना में आसान है, लेकिन promotion अक्सर complex solutions बनाने वालों को मिलता है
- Micah Goldblum का कहना है कि ML reviews में यह आपत्ति आम है कि तरीका बहुत simple है या existing parts से बना है, जबकि simplicity कमजोरी नहीं बल्कि ताकत है
- Kalman Filters, PageRank, SVM, LSTM, Word2Vec, Dropout जैसी innovations भी कभी reject की जा चुकी हैं
जटिलता को संभालने के बेहतर तरीके
- लक्ष्य है जटिल समस्याओं को जितना संभव हो उतने सरल समाधान से हल करना
- ध्यान समाधान की जटिलता पर नहीं, समस्या की जटिलता पर होना चाहिए
- सरल समाधान समस्या की गहरी समझ और अधिक उलझे, महंगे समाधानों से बचने की क्षमता दिखाता है
- यह Albert Einstein के इस कथन से जुड़ता है: “हर चीज़ को जितना संभव हो उतना सरल होना चाहिए, लेकिन उससे अधिक सरल नहीं”
- सब कुछ समेटने वाले जटिल समाधान की जगह कई focused solutions पर विचार किया जा सकता है
- one-size-fits-all समाधान अपेक्षा से कम flexible और कम reusable हो सकता है
- कई use cases और stakeholders को एक साथ support करने पर system tightly coupled हो सकता है, और planning व migration में अधिक coordination चाहिए होता है
- single-purpose systems को operate करना आसान होता है, और ज़रूरत पड़ने पर उन्हें हटाना भी आसान होता है
- Occam’s razor complexity bias को कम करने का एक तरीका हो सकता है
- इसका सिद्धांत है कि सबसे सरल समाधान या explanation अक्सर सही होता है
- simple ideas को बहुत जल्दी खारिज नहीं करना चाहिए, और value justify करने के लिए अनावश्यक जटिलता नहीं जोड़नी चाहिए
- जटिलता की लागत को ध्यान में रखकर पूछना चाहिए: “क्या यह वास्तव में इसके लायक है?”
जानी-पहचानी जटिलता को reuse करने वाला उलटा bias
- “not invented here” के उलट, existing components को अपने-आप पसंद करने वाला bias भी होता है
- क्योंकि वे पहले से परिचित होते हैं, व्यक्तिगत अनुभव के आधार पर आसान लगते हैं, और अपना समय व मेहनत बचाते हैं
- लेकिन अगर existing component खुद बहुत जटिल हो, तो वह कुछ सरल नया बनाने की तुलना में ज़्यादा समय और resources बर्बाद कर सकता है और बदतर परिणाम दे सकता है
- जब कोई सरल विकल्प न हो, तब नया बनाना ज़रूरी हो सकता है
- लेकिन कई बार नया बनाया गया समाधान वास्तव में सरल नहीं बनता, बल्कि existing चीज़ जितनी ही जटिल कोई दूसरी चीज़ बन जाता है
- कुछ समस्याएँ स्वभाव से ही जटिल होती हैं और उनमें ऐसी essential complexity होती है जिसे वास्तव में हटाया नहीं जा सकता
- ORM को एक बुरे उदाहरण के रूप में लिया गया है
- ORM बार-बार नए सिरे से बनाए जाते हैं और शुरुआत में सरल लगते हैं, लेकिन अंततः उनकी complexity फट पड़ती है
- object/relational impedance mismatch एक जानी-पहचानी समस्या है, और ORM का विचार ही मूलतः जटिल है
- जो चीज़ सादगी बनाए रखने वाली लगती है, वह शायद ORM नहीं बल्कि query builder या data mapper होती है
- PSR cache API हटाई जा सकने वाली जटिलता का उदाहरण है
- PSR-6 cache API के बाद एक अधिक सरल PSR-16 cache API आया
- PSR-16 ने complexity और concepts की संख्या घटाकर API को छोटा और कम opinionated बनाया
- PSR-16 implementation के लिए PSR-6 adapter और उलटी दिशा का adapter बनाया जा सकता है, जो दिखाता है कि PSR-16 में हटाई गई complexity essential नहीं थी
- कुछ libraries और frameworks developer experience के नाम पर essential complexity से भी आगे बढ़ सकते हैं
- वास्तविक simplicity को lines of code, public methods की संख्या, coupling जैसे metrics से मापा जा सकता है
- कुछ libraries कुछ ही वर्षों में अपने मूल आकार से 10 गुना बड़ी हो जाती हैं और हर 6–12 महीने में बड़े breaking changes जारी करती हैं
- जिस library में growth न हो उसे “dead” मानकर अधिक “active” package पर जाना चाहना भी complexity bias का लक्षण हो सकता है
- फैलती हुई complexity से बचने के लिए कभी-कभी नया बनाना सही विकल्प होता है
- अगर requirements को स्थिर रखा जा सके और scope creep जैसी वृद्धि से बचा जा सके, तो नई implementation अधिक सरल विकल्प हो सकती है
- ध्यान रखना चाहिए कि किसी भी दिशा का bias मज़बूत न हो
1 टिप्पणियां
Hacker News की राय
मैं FAANG की एक कंपनी में उस दौर में काम करता था जब जटिल समस्याएं हल करना प्रमोशन का मापदंड था; जितनी ज्यादा जटिल समस्या आप हल करते, आपका level, compensation और status उतना ऊपर जाता था
स्वाभाविक रूप से लोग हल करने लायक जटिल समस्याएं ढूंढने लगे, और जैसे-जैसे दूसरी कंपनियों ने उस कंपनी के ideas कॉपी किए, लगता है छोटी कंपनियों तक के पास, जिन्हें जटिल solutions की जरूरत नहीं थी, मिलते-जुलते tech stack आ गए
आजकल कारों के UI, खासकर EVs के जटिल और इस्तेमाल में मुश्किल UI देखकर मेरे मन में भी ऐसा ही विचार आया, और यह मुझे वह कार खरीदने से रोकने के लिए काफी है जिसे इसकी जरूरत होती है
निष्कर्ष यह है कि sophisticated consumer और aspirational consumer बहुत अलग होते हैं, और aspirational consumers कहीं ज्यादा हैं
इसलिए sophisticated consumer की कीमत पर aspirational consumer के हिसाब से बनाना आर्थिक रूप से वाजिब है
aspirational consumer खामियों और दिखावे को उपभोग-उपलब्धि के प्रतीक की तरह स्वीकार करता है, इसलिए उन्हें झेलता है
मोटे तौर पर कहें तो “luxury” कार चलाने का उसे इतना आनंद है कि साथ आया कचरा दिखता ही नहीं; और दशकों से luxury कारें खरीदते आए व्यक्ति के रूप में मैं बस चाहता हूं कि gear selector समझने में आसान हो
touch targets बिना वजह बहुत छोटे हो गए, और लगता है developers ने UI को fixed desk display पर या न चल रही कार में बनाया और test किया
चलती कार के अंदर सब कुछ बिगड़ जाता है
gear selector, indicators, wiper और light stalks के बिना नई cars तो पूरी अव्यवस्था हैं
ऐसी screen पर, जहां हाथ टिकाने की जगह भी नहीं है, driver seat पर बैठकर छोटे targets पर सटीक tap करना पड़ता है; indirect control, confusion, inaccuracy और distraction की वजह से ये सबको खराब driver बनाता है
lock/unlock, windows बंद करना, pre-heat/pre-cool, सुबह office और शाम को घर के लिए automatic navigation set करना, कौन-सी phone key इस्तेमाल हुई उसके आधार पर seat और settings adjust करना जैसे झंझट अपने-आप हो जाते हैं
free connectivity की वजह से navigation भी ठीक से चलता है, जबकि पहले जिन in-car GPS systems को इस्तेमाल किया था वे सब बेकार थे
music selection और playback screen भी अच्छी है, और voice commands भी music selection के लिए काफी ठीक काम करती हैं
यह perfect नहीं है, लेकिन अब तक चलाए गए हर internal combustion car से बेहतर लगता है
सुबह office निकलने की प्रक्रिया बस दो steps में खत्म हो जाती है: दरवाजा खोलना, drive mode में डालना
सर्दियों में internal combustion car में key ढूंढना, car unlock करना, door खोलना, पत्नी के चलाने के बाद seat adjust करना, start button दबाना, windshield defrost करना, rear window heater, windshield से ice खुरचना, GPS में office चुनना, parking brake release करना, clutch दबाना, gear लगाना—10 से ज्यादा steps होते थे
जिन लोगों के पास खुद नहीं है वे online touchscreen को लेकर लगातार रोते रहते हैं, लेकिन Tesla owners touchscreen हो या न हो, दूसरी cars से बेहतर होने के कारण उसी brand में बने रहते हैं
Technology Connections ने हालिया video में कहा कि wiper बदलने के लिए उन्हें 90s-style बदसूरत lever को 4 seconds तक पकड़े रखना पड़ा, और यह पता करने के लिए manual पढ़ना पड़ा
अलग-अलग चिपकाए गए parts से बनी cars में ऐसी बेकार हरकतें बहुत आम हैं
इसके उलट मेरी car real-time surveillance video alerts phone पर भेजती है, office commute पर driving कर देती है, और gear shifting आम तौर पर इतना है कि seatbelt लगाकर brake दबाने पर car खुद direction चुन लेती है
जरूरी functions 50 buttons से नहीं, बल्कि steering wheel से context के हिसाब से access किए जा सकते हैं
यह simple भी है और powerful भी; समस्या यह है कि ऊपर बताई गई luxury cars का execution बेहद खराब है
Theo Browne नाम के YouTuber को कभी-कभी देखता हूँ; वह मुख्यतः frontend developer हैं
जब वह समाधान समझाते हैं तो ऐसा लगता है जैसे सिर पर बेसबॉल बैट पड़ गया हो, और demo में जाने वाले elements की संख्या देखकर रोना आ जाए
एक वीडियो में वह React से जुड़े जितने कठिन terms बोलते हैं, उससे भी हैरानी होती है
किसी खास व्यक्ति को निशाना बनाकर आलोचना करने का इरादा नहीं है, लेकिन चिंता होती है कि कहीं वही जटिलता उनकी लोकप्रियता बनाए रखने की वजह तो नहीं
दूसरी तरफ Pieter Levels Suspense, server-side rendering, Hydration जैसी बातें किए बिना सीधे plain PHP को production में डाल देते हैं
दोनों आखिरकार एक ही लक्ष्य तक पहुँचते हैं, लेकिन लगता है Pieter Levels कहीं ज्यादा पैसा कमाएँगे, और complexity का अंतर बहुत बड़ा है
असल में Nomad List जैसी चीज़ें Theo के यहाँ दिखने वाली चीज़ों से कहीं ज्यादा feature-rich लगती हैं
बाद में किसी और ने उन्हें पहचान लिया, और मैंने देखा कि Theo अपने channel पर जिस विषय पर ज़ोरदार ढंग से बोल चुके थे, उसी पर दोस्ताना लेकिन ऊँची आवाज़ वाली बहस कर रहे थे
उनका व्यक्तित्व अनावश्यक complexity के ज़रिए media engagement को अधिकतम करने के लिए बिल्कुल उपयुक्त लगा
जितनी ज्यादा complexity, उतने ज्यादा विवाद के मुद्दे, और कठिन विकल्पों से परिचित न लोगों को आप उतने ही ज्यादा बुद्धिमान लग सकते हैं
खिलौने जैसे examples में इस्तेमाल होने वाली libraries और code की मात्रा production में दिखने वाली चीज़ों से कहीं ज्यादा होती है, और मैंने भी काफी monster systems देखे हैं
पता नहीं यह कितने समय तक चलेगा
उसमें ढेर सारी ऐसी चीज़ें शामिल होती हैं जिन्हें आप इस्तेमाल नहीं करेंगे, और जो हिस्सा इस्तेमाल करना है उसी में बाधा डालती हैं
समस्या आने पर अब आपको programming language और अपने code के अलावा framework के भीतर उस path का code भी समझना पड़ता है जिससे आपका flow गुजर रहा है
वह path आसानी से 10–20 functions की depth तक जा सकता है, और अलग-अलग edge cases में क्या होता है, यह पर्याप्त concrete तरीके से documented होना बेहद दुर्लभ है
अपेक्षाकृत सरल चीज़ बनाने के लिए इस्तेमाल होने वाले tools की मात्रा जबरदस्त है, और DevOps में भी कुछ ऐसा ही होता महसूस होता है
लगता है यह समस्या कंपनियों के “frontend developers” ने बनाई है
full-stack या backend developers द्वारा किए जाने वाले “real engineering” को लेकर किसी तरह की हीनभावना ने शायद frontend में भी “real engineering” problems पैदा करने की इच्छा जगा दी
दशकों तक legacy systems पर development करते हुए, कभी अपनी कंपनी के design में और कभी customer contract work में, मैंने ऐसी कई चीज़ें देखीं जिनसे मुझे यकीन हुआ कि कुछ ग्राहक complex और bug-filled software को पसंद करते हैं
वजह यह है कि वे उसके पीछे छिप सकते हैं
जैसे, “software में bug था इसलिए समय पर पूरा नहीं कर पाया”, “software Y support नहीं करता इसलिए X नहीं कर सका”, “कुत्ते ने homework खा लिया” वगैरह
कई मामलों में सरल, आसान और बहुत कम bug वाला solution design किया जा सकता था, लेकिन तब users के लिए यह छिपाना मुश्किल हो जाता कि कोई खास failure software की समस्या नहीं बल्कि उनकी अपनी अक्षमता की वजह से हो सकता है
इसलिए खासकर उन कंपनियों में जहाँ ऊपर से दबाव ज्यादा होता है, managers सच में ऐसे software के साथ काम करना पसंद करते हैं जिसे वे पूरी तरह समझते नहीं और जिसके बारे में पता है कि उसमें bugs और problems हैं
27 साल की उम्र में, पहली नौकरी में 5 साल बाद जब job बदली, तो मैंने एक बेहद complex GUI program को दो CLI programs को wrap करने वाले छोटे GUI से replace कर दिया
गलत input आने पर भी वह हर बार काम करता था, और कभी-कभार fail होने पर उपयोगी error message देता था
उसका इस्तेमाल करने वाली तीन महिलाएँ मुझसे सचमुच नफरत करती थीं
कंपनी छोड़ने के करीब एक साल बाद जाकर वजह समझ आई, और उस समय मैं बहुत समझदार नहीं था
समय के साथ मुझे लगने लगा कि लोग Microsoft Teams जैसी चीज़ें चाहते हैं, क्योंकि जरूरत पड़ने पर वे उससे अपनी गड़बड़ियाँ ढक सकते हैं
physical UI में हमारा group इसे microwave problem कहता है
microwave पर लगे 20 extra buttons कोई इस्तेमाल नहीं करता और ज्यादातर लोग सिर्फ एक-दो buttons ही इस्तेमाल करते हैं, लेकिन कम buttons वाला microwave कोई नहीं खरीदता
10 साल से Samsung ME82V पसंद है, और दो dials ही काफी हैं
इसलिए रात 2 बजे चोरी-छिपे snack खाना 1999 की तरह microwave को ताकते रहने वाला काम बन जाता है
चाहिए तो बस speed dial, momentary switch, power switch हैं और हर कोई यही चाहता है, लेकिन न जाने क्यों हर नई generation में ऐसे ढेरों features जुड़ जाते हैं जिन्हें कोई इस्तेमाल नहीं करता
जरूरी नहीं कि हमेशा वही दो buttons इस्तेमाल किए जाएँ, इसलिए दूसरे buttons इस्तेमाल कर सकने का option पसंद आता है
और काफी बार ज्यादा buttons के साथ बेहतर specs भी मिलते हैं
controls भी कम, features भी कम, लेकिन user experience शानदार था
जरूरत से ज्यादा features और जटिलता वाले competing products की तुलना में iPod की सफाई याद आती है
ऐसी शिकायतें घिसी-पिटी कहावतों से भरी होती हैं, इसलिए चिढ़ होती है
Einstein और Dijkstra को quote करके स्मार्ट दिखना आसान है, और hindsight के फ़ायदे व असली requirements की अनदेखी के साथ complex solutions को generalize करके उंगली उठाना भी आसान है
“जितना हो सके उतना simple, लेकिन उससे ज़्यादा simple नहीं” हमेशा सही बात है
अगर solution गंदा है तो उसे और simple बनाना चाहिए था, और अगर primitive solution दिक्कत पैदा करे तो उसे इतना simple नहीं बनाना चाहिए था
मतलब, आपने बस perfect बनाने के बारे में क्यों नहीं सोचा
असलियत में, जब किसी solution में कई trade-offs हों, तो यह तय करना भी बहुत मुश्किल होता है कि simple क्या है
एक complex database maintain करना शायद तीन “simple” databases रखकर admin काम तीन गुना करने और अंत में sync या distributed transactions implement करने से आसान हो सकता है
जो अभी implement करना आसान है, वह बाद में complex समस्याएँ बना सकता है, और कोई off-the-shelf solution जो समस्या को पूरी तरह solve नहीं करता, unsupported cases के लिए complex workarounds पैदा करता है और अंत में सही चीज़ पर migrate करने की complexity भी जोड़ देता है
“बस simple रखो” वाली सलाह अक्सर यह नहीं समझती कि ऐसा solution कोई रामबाण नहीं है, और complex बनाम simple के साफ़ विकल्प असल दुनिया में कम ही मिलते हैं
projects पर मौजूदा messy systems, inconsistent legal requirements, बदलती business needs जैसी constraints होती हैं, और release speed या hire की जा सकने वाली skills को भी प्राथमिकता देनी पड़ सकती है
economics भी निर्दयी है: annual report निकालना Rube Goldberg machine जैसा हो, फिर भी अगर साल में बस एक बार इस्तेमाल होता है, तो उसे फिर से लिखने पर 50 साल में भी cost recover न हो सकती है
complexity पर चर्चाएँ अक्सर यह बात नहीं मानतीं कि projects और requirements बढ़ते हैं
जो अभी perfectly simple है, वह बाद में अक्षमता या दुर्भावना के कारण नहीं, बल्कि पूरी तरह rational तरीके से complex हो सकता है
शुरुआत में data को plain text file में store करना खूबसूरती से simple है, लेकिन बाद में वह घटिया NIH database बन सकता है
फिर भी 3 lines data के लिए शुरुआत से database इस्तेमाल करना भी overengineering है
refactoring की cost होती है, इसलिए हमेशा ideal solution इस्तेमाल करना भी इतना simple नहीं है
जितना हम सोचते हैं, उससे कहीं कम चीज़ें सच में obvious होती हैं
“जितना हो सके उतना simple, लेकिन उससे ज़्यादा simple नहीं” को perfection की मांग के रूप में पढ़ना logically follow नहीं करता
practice में हम जानते हैं कि iteration planning को हरा देता है
अगर इस पर सहमति बनाना मुश्किल है कि simple क्या है, तो permission मत मांगो, forgiveness मांगो
यह नियम इस industry में, और शायद कई दूसरी industries में भी, चलता है
dreamers और front-end developers में दिखने वाली accidental complexity की एक खास type निश्चित रूप से है
complexity, complex होती है
ज़्यादा complex systems का secondary effect यह भी होता है कि वे tutorials, videos जैसी बहुत सारी surrounding material पैदा करते हैं
साथ ही, जिन लोगों ने उसे सीखा है, वे company में ज़रूरी skills और responsibilities वाले बन जाते हैं, इसलिए किसी ऐसी चीज़ की तुलना में जो बस ठीक से चलती है और ऐसे लोगों की ज़रूरत ही नहीं पड़ती, उन्हें job security मिलती है
IT में ऐसी बहुत-सी नौकरियाँ हैं जो software को simple और बस काम करने वाला बनाया गया होता तो होती ही नहीं
simple cases में यह “बस काम करता है”, लेकिन जब तक आप इसके अंदर झांकने या कोई non-trivial काम करने की कोशिश नहीं करते, सब ठीक है
शायद analogy काफी सही हो
अगर बात paper review की है, तो reviewer के रूप में मैं papers में simplicity या complexity नहीं ढूंढता, और “novelty” भी नहीं
मैं समस्या पर thorough और thought-provoking empirical analysis ढूंढता हूँ
submissions में बहुत कुछ ऐसा होता है: 1) existing ideas के दर्जन भर टुकड़ों को जोड़कर Frankenstein जैसा system propose करना, और हर हिस्से के failure modes का गहरा analysis किए बिना हाथ लगने वाले नए-नए toys का maximum इस्तेमाल करके “बड़े numbers” हासिल कर लेना, 2) existing method में बस थोड़ा बदलाव किया तो संयोग से performance बेहतर हो गई, लेकिन यह क्यों मदद करता है, इसकी उचित empirical या theoretical justification नहीं
दूसरा type community या readers के लिए बहुत थोड़ा value रख सकता है, लेकिन मैं इसे ज़्यादातर बेकार मानता हूँ
readers के लिए value तब होती है जब कोई PhD student किसी problem को लंबे समय तक देखने के बाद अपनी intuition को quantitative और verifiable confirmation से जोड़ता है, और predictive power वाली reproducible observations पाता है
जैसे “इस paper में बताए गए Z mechanism के जरिए X, Y को affect करता है, यह हमने सभी cases में experimentally verify किया, इसलिए A metric B% improve हुआ और यह Z के consistent है”
complexity से अलग, “हमने X किया तो A B% बढ़ गया” जैसी बात पर्याप्त नहीं है
अफ़सोस, सभी reviewers इससे सहमत नहीं होते
high school के history teacher ने World War II तक ले जाने वाली घटनाओं पर essay लिखने का assignment दिया
पहला सवाल था कि length कितनी होनी चाहिए, और teacher ने जवाब दिया कि अगर इस complex topic को A4 के एक page में cover कर सकते हो तो full marks दूँगा, लेकिन उन्हें सच में शक है कि इतने छोटे लेख में यह हो पाएगा
सब उस logic से चौंक गए
किसी ने teacher को ऐसा कहते नहीं सुना था, और यह दिखाता है कि बचपन से हमें सिखाया जाता है कि ज़्यादा हमेशा बेहतर होता है
explanation में हमेशा abstraction level चुनकर उसे लंबा या छोटा बनाया जा सकता है, और लोग आम तौर पर context और social conventions के हिसाब से वह level चुनते हैं
उदाहरण के लिए “key press कैसे screen पर character बनता है” एक sentence में भी समझाया जा सकता है, और firmware, software stack, electronics, materials science, manufacturing process तक जाएँ तो कई लंबी books में भी
World War II के बारे में भी कहा जा सकता है कि यह Hitler द्वारा Poland और France पर invasion से शुरू हुआ, या Versailles Treaty तक जा सकते हैं, या पृथ्वी पर life के evolution तक भी बात ले जा सकते हैं
आख़िरी वाला pedantic है, लेकिन technically वह World War II तक ले जाने वाली घटना है
Rich Hickey की Simple Made Easy talk की ज़ोरदार सिफारिश करता/करती हूँ
complexity बिल्कुल भी अच्छी नहीं बिकती, लेकिन easy चीज़ें अच्छी बिकती हैं
अगर कोई company ऐसे बहुत से लोगों को hire कर सकती है जो ‘foo’ इस्तेमाल करना जानते हैं और industry लगातार ‘foo’ की बात करती रहती है, तो foo पूरी तरह अव्यवस्थित होने पर भी वे उसी को चुनेंगे
lambda architecture, ज़्यादातर Apache projects, containers वगैरह को देख लें