सादगी के फायदे के बावजूद, अफ़सोस कि जटिलता ज्यादा बिकती है

सादगी के फायदे के बावजूद, अफ़सोस कि जटिलता ज्यादा बिकती है

जटिलता क्यों ज्यादा बिकती है?

• जटिलता प्रयास का संकेत देती है
  • कठिन आइडिया और तकनीकी विवरण वाले शोधपत्र खून-पसीना याद दिलाते हैं
  • अधिक घटकों और फीचर्स वाला सिस्टम कम घटकों वाले सिस्टम की तुलना में अधिक मेहनत वाला लगता है
  • जटिल परिणाम को यह मानकर देखा जाता है कि उसे बनाने में ज्यादा परिश्रम लगा होगा, इसलिए वह कठिन और अधिक मूल्यवान लगता है
  • जटिलता से जुड़ी मेहनत के कारण अक्सर इसे बेहतर गुणवत्ता वाला माना जाता है
• जटिलता निपुणता का संकेत देती है
  • कई moving parts वाला जटिल सिस्टम दिखाता है कि डिज़ाइनर प्रत्येक हिस्से पर महारत रखता है और उन्हें जोड़ने में सक्षम है
  • समझना कठिन, तकनीकी शब्दावली और proof से भरा शोधपत्र विषय की विशेषज्ञता दर्शाता है
  • अगर किसी आम आदमी के लिए कोई जटिल आइडिया या सिस्टम समझना कठिन हो, तो उसका creator शायद विशेषज्ञ होगा
• जटिलता नवाचार का संकेत देती है
  • बिल्कुल नया मॉडल आर्किटेक्चर बनाने वाला पेपर, मौजूदा नेटवर्क लागू करने वाले पेपर से ज्यादा नया माना जाता है
  • शुरुआत से बनाए गए components वाला सिस्टम existing components reuse करने वाले सिस्टम की तुलना में ज्यादा creative माना जाता है
  • पहले के काम पर आधारित या उसे पुनः उपयोग करने वाला काम उतना innovative नहीं दिखता
• जटिलता का मतलब अधिक फीचर होना भी है
  • mix तथा match किए जा सकने वाले components वाला सिस्टम अधिक आधारों को कवर करने की लचीलापन देता लगता है
  • जटिल सिस्टम में सरल सिस्टम की तुलना में अधिक blocks होते हैं, इसलिए उसे अधिक अनुकूलनशील और बदलावों के प्रति अधिक responsive माना जाता है

सादगी क्यों बेहतर है

• सरल आइडिया और फीचर समझने और इस्तेमाल करने में आसान होते हैं
  • इससे अपनाने की संभावना बढ़ती है और प्रभाव बनता है
  • संवाद करना और फीडबैक पाना भी आसान होता है
  • इसके विपरीत, जटिल सिस्टम को समझाना और manage करना कठिन होता है, जिससे उपयोगकर्ता को यह समझना मुश्किल होता है कि उसे क्या और कैसे करना है
• सरल सिस्टम को बनाना और स्केल करना आसान होता है
  • जितने कम components होंगे, उसे उतना आसान लागू किया जा सकता है
  • standard off-the-shelf तकनीक इस्तेमाल करने से इसे implement और maintain कर सकने वाले सही लोग ढूँढ़ना आसान होता है
  • सरल सिस्टम में कम complexity, कम code और सिस्टम के अंदर कम interactions होने से उसे समझना और टेस्ट करना आसान होता है
  • जबकि अनावश्यक रूप से जटिल सिस्टम अधिक समय और संसाधन मांगते हैं, जिससे inefficiency और waste बढ़ता है
• सरल सिस्टम की ऑपरेशनल लागत कम होती है
  • सिस्टम deployment फिनिश लाइन नहीं, बल्कि शुरुआत की लाइन है
  • अधिकांश प्रयास उस समय लगता है जब सिस्टम production environment में होता है; इसे सरल रखकर maintenance cost कम की जा सकती है और lifespan बढ़ाई जा सकती है
• मशीन लर्निंग में सरल तकनीकें अक्सर अधिक जटिल तकनीकों से पीछे नहीं रहतीं
  • tree-based मॉडल medium-sized tabular data पर deep neural network से बेहतर रहे
  • greedy algorithm ने combinatorial graph समस्या में graph neural network को पीछे छोड़ा
  • simple averaging ने multi-task learning समस्या में complex optimizer के बराबर या बेहतर प्रदर्शन दिखाया
  • 32 शोध-पत्रों में prediction accuracy के आधार पर सरल तरीका, जटिल तरीके से बेहतर रहा
  • recommendation और search में inner product, neural collaborative filtering से बेहतर performance देता है

जटिलता को पुरस्कृत करने की समस्या

• लोगों को अनावश्यक जटिलता बनाने के लिए प्रेरित किया जाता है
  • सरल तरीका अपनाना या सरल सिस्टम बनाना आसान दिखने के कारण कम मूल्यवान समझा जाता है
  • नतीजतन लोग ज्यादा reward के लिए सिस्टम को tweak करने लगते हैं और सबसे सरल समाधान अब सबसे obvious विकल्प नहीं रहता
• "Not Invented Here" सोच को बढ़ावा मिलता है, जबकि समय और मेहनत बचाने के लिए existing components reuse किए जा सकते हैं, फिर भी शुरुआत से ही निर्माण करने को पसंद किया जाता है
  • इससे समय और संसाधनों की बरबादी होती है और अक्सर खराब परिणाम निकलते हैं

जटिलता के बारे में कैसे सोचना चाहिए?

• लक्ष्य यह होना चाहिए कि संभव हो सके तो जटिल समस्या का समाधान सबसे सरल तरीके से खोजा जाए
  • समाधान की complexity पर नहीं, समस्या की complexity पर फोकस किया जाना चाहिए
  • सरल समाधान समस्या की गहरी समझ और अधिक जटिल तथा महंगे समाधान से बचने की क्षमता दिखाता है
• सभी मामलों का समाधान करने वाले जटिल समाधान की जगह कई focused समाधानों पर विचार करें
  • एक ही समाधान अक्सर उतना flexible या reusable नहीं होता जितना अपेक्षित रहता है
  • क्योंकि वह कई उपयोग मामलों और हितधारकों के लिए मौजूद होता है, इसलिए अक्सर “tightly coupled” होता है और planning तथा migration में ज्यादा समन्वय की जरूरत पड़ती है
  • जबकि single-purpose सिस्टम चलाना और retire करना आसान होता है

GN⁺ की राय

• यह लेख अच्छी तरह समझाता है कि जटिलता क्यों पसंद की जाती है और सरलता के फायदे क्या हैं। जटिलता इसलिए पसंद की जाती है क्योंकि वह निपुणता, नवाचार और फीचर का संकेत देती है—यह हिस्सा खासा रोचक था।
• लेकिन हर मामले में सरल समाधान बेहतर हो, यह मानना कठिन है। समस्या के स्वभाव के अनुसार कुछ स्तर की जटिलता जरूरी हो सकती है। सरलता और जटिलता में सही संतुलन ज़रूरी है।
• मशीन लर्निंग में सरल मॉडलों के बेहतर प्रदर्शन वाले उदाहरण रोचक थे। नया मॉडल बनाते समय पहले से मौजूद सरल methods से तुलना करना बेहतर होगा।
• संगठन में performance evaluation करते समय जटिलता पर बहुत ज्यादा जोर न देने पर ध्यान देना चाहिए। इसके बजाय समस्या की कठिनाई और समाधान की प्रभावशीलता पर फोकस करना बेहतर होगा।
• आर्किटेक्चर डिजाइन में one-size-fits-all जटिल सिस्टम की जगह कई single-purpose सरल सिस्टम पर विचार करना भी एक अच्छा तरीका हो सकता है।

[GN⁺]

Hacker News टिप्पणी

सार:

• MVP (न्यूनतम फंक्शनल उत्पाद) को बार-बार जोड़ते जाने का तरीका भी कई बार जटिलता का कारण बन सकता है
• कठिन समस्याओं को सुलझाने पर ज़्यादा रिवार्ड देने वाली प्रणालियाँ उलटा अनावश्यक जटिलता पैदा कर सकती हैं
• उन्नत और आकांक्षी उपभोक्ताओं की जरूरतों के अंतर के कारण, कंपनियों के लिए आकांक्षी उपभोक्ता की मांगें पूरी करना अक्सर तार्किक विकल्प बन जाता है
• जटिल और बग-ग्रस्त सॉफ़्टवेयर को उल्टा इसलिए भी पसंद किया जाता है क्योंकि उसके पीछे छिपा जा सकता है
• बचपन से ही 'अधिक चीज़ें बेहतर हैं' वाली सोच की आदत पड़ जाती है
• इंजीनियर के रूप में हम सरल समाधान की तुलना में चुनौतीपूर्ण चीज़ों में ज्यादा आकर्षण महसूस करते हैं
• हम सरल चीज़ों को पसंद भी करते हैं, लेकिन वही चीज़ जो सरल दिखे उसे अक्सर नापसंद करते हैं—यह एक विरोधाभासी मनोविज्ञान है
• बाद में किसी जटिल समाधान की आलोचना करना आसान है, लेकिन उस समय की सीमाओं और जरूरतों को जाने बिना की गई आलोचना खोखली होती है
• 'जितना संभव हो उतना सरल, लेकिन अत्यधिक सरल नहीं' का सिद्धांत हमेशा सही होता है, लेकिन उसे लागू करना आसान नहीं
• कई बार कोई प्रोजेक्ट शुरू में सरल होता है, लेकिन मांगें बढ़ने पर उसका अनिवार्य रूप से जटिल हो जाना तय हो जाता है