सिद्धांत जो पहले से मौजूद था
हर MOAD दोष के लिए 2026 में व्यवस्थित पहचान से दशकों पहले एक ज्ञात समाधान मौजूद था। दोष इसलिए बने नहीं रहे क्योंकि कोई बेहतर समाधान नहीं जानता था। वे इसलिए बने रहे क्योंकि जानना और पहचानना एक ही बात नहीं है।
MOAD-0001: O(N²) list.contains
डोनाल्ड नुथ, 1973. द आर्ट ऑफ़ कंप्यूटर प्रोग्रामिंग, वॉल्यूम 3: सॉर्टिंग एंड सर्चिंग. O(1) लुकअप के लिए हैश टेबल्स 1973 में पूर्ण विश्लेषण सहित निर्दिष्ट किए गए थे। O(N) रैखिक खोज और O(1) हैश लुकअप के बीच का अंतर — प्रलेखित, औपचारिक, व्यापक रूप से उद्धृत। Java ने HashSet 1.0 (1996) में भेजा। Python ने set को 2.4 (2004) में प्रथम-श्रेणी प्रकार के रूप में भेजा। हर पारिस्थितिकी तंत्र में यह एक डिफ़ॉल्ट मुहावरा बनने से 30 साल पहले समाधान मौजूद था।
Richard Hamming, 1986. Bell Labs lectures (later published as The Art of Doing Science and Engineering, 1997). Hamming explicitly taught algorithmic complexity, the difference between correct & efficient, & the danger of building systems that work at small scale but fail at large. He called it 'designing for the problem you can see today, not the problem you will face tomorrow.'
MOAD-0002: Shared Global State Coupling
David Parnas, 1972. 'On the Criteria To Be Used in Decomposing Systems into Modules.' CACM, December 1972. Parnas argued that modules should be decomposed by information hiding — each module owns its state, no shared mutable globals. This is the direct theoretical predecessor of the Intertangle fix. Parnas was explicit: global shared state creates invisible coupling that testing does not reveal.
MOAD-0003: ThreadLocal Identity Leak
Java 1.2, 1998. ThreadLocal shipped as a Java standard library class. The moment thread pooling + ThreadLocal coexisted, the mechanism for the leak existed. The defect is structural: a carrier whose lifetime is the thread, not the unit of work. Documentation warned about this from early in the Java EE lifecycle.
MOAD-0004: Logged Credentials
RFC 1945, 1996. HTTP/1.0 defined the Authorization header. The credential logging defect became possible the day the Authorization header existed. OWASP was founded in 2001 and documented credential logging as a vulnerability class in its first guides. The pattern: Authorization header → log middleware → cleartext credentials on disk. Knowable since the first HTTP auth spec.
MOAD-0005: Thundering Herd / Cache Stampede
Unix kernel, 1993. 'थंडरिंग हर्ड समस्या' — एक साझा घटना पर N प्रक्रियाओं का एक साथ जागना — 1990 के दशक के आरंभ में Unix कर्नेल विकास चर्चाओं में दिखाई दी। डौग श्मिट का रिएक्टर पैटर्न (1994) और हाफ-सिंक/हाफ-एसिंक (1995) पर कार्य इंफ्रास्ट्रक्चर स्तर पर सिंक्रोनाइजेशन को संबोधित करता है। कैश स्टैम्पीड वैरिएंट (कैश मिस पर N थ्रेड्स एक ही मान की गणना करते हैं) 2001 तक वितरित सिस्टम साहित्य में दस्तावेजित किया गया था। [BLOCK_TYPE knowable/theory_exists]
--- [BLOCK_TYPE knowable/theory_exists]
सिद्धांत: पूर्ण। डिटेक्शन टूलिंग: अनुपस्थित। 'जानने योग्य' और 'पता लगाए गए' के बीच का अंतर 28 से 54 वर्ष तक चलता है, दोष के आधार पर। [BLOCK_TYPE knowable/knowable_question]
The Knowability Gap [BLOCK_TYPE knowable/knowable_question]
टाइमलाइन दिखाती है कि हर MOAD दोष के लिए कम से कम 28 वर्ष पहले एक ज्ञात समाधान मौजूद था। सबसे छोटा अंतर (MOAD-0003) 28 वर्ष है। सबसे लंबा (MOAD-0002) 54 वर्ष है। [BLOCK_TYPE knowable/knowable_question]
यह अज्ञान की कहानी नहीं है। Knuth, Parnas, Hamming — ये कंप्यूटर विज्ञान के सबसे अधिक उद्धृत लेखक हैं। उनका कार्य विश्वविद्यालयों में पढ़ाया जाता था। उनकी शब्दावली (Big O, information hiding, algorithmic complexity) मानक पाठ्यक्रम बन गई। [BLOCK_TYPE knowable/knowable_question]
Why Code Festers: Five Conditions
कोई दोष संयोग से नहीं टिकता। पाँच संरचनात्मक शर्तें, जब एक साथ मौजूद हों, एक fester वातावरण बनाती हैं। उनमें से कोई एक भी हटा दें तो डिटेक्शन संभव हो जाता है।
Condition 1: Correct Output
एक सूची और एक सेट सदस्यता प्रश्न का उत्तर समान रूप से देते हैं। list.contains(x) और set.contains(x) एक ही बूलियन लौटाते हैं। एक ThreadLocal पुरानी पहचान ले जाता है, फिर भी वह एक पहचान ले जाता है — वह केवल गलत अनुरोध से संबंधित होती है। लॉग की गई क्रेडेंशियल्स सही ढंग से लॉग होती हैं — क्रेडेंशियल बिना किसी त्रुटि के लॉग फ़ाइल तक पहुँच जाती है। दोष कोई खराबी नहीं है। यह केवल लागत या सुरक्षा परिणाम में खराबी है। आउटपुट जाँचने वाले टेस्ट पास होते हैं। लागत या सुरक्षा परिणाम जाँचने वाले टेस्ट: अधिकतर लिखे नहीं गए हैं।
[BLOCK_TYPE five_conditions/conditions_diagram]
Condition 2: CI में कोई जटिलता टेस्ट नहीं
[BLOCK_TYPE five_conditions/conditions_diagram]Dijkstra ने कहा 'टेस्टिंग दोषों की उपस्थिति दिखाती है, न कि उनकी अनुपस्थिति।' Hamming ने इसे आगे बढ़ाया: जिन दोषों के लिए हम टेस्ट करते हैं, वही दोष हमें मिलते हैं। 2026 में CI पाइपलाइनें टेस्ट करती हैं: शुद्धता, प्रकार सुरक्षा, API अनुबंध, कार्यात्मक व्यवहार। वे टेस्ट नहीं करतीं: प्रति ऑपरेशन एल्गोरिदमिक जटिलता, प्रति-कॉल मेमोरी वृद्धि, प्राधिकरण-हेडर स्क्रबिंग, थ्रेड पहचान जीवनचक्र। [BLOCK_TYPE five_conditions/conditions_diagram]
कोई टेस्ट नहीं चलता। कोई टेस्ट विफल नहीं होता। पाइपलाइन हरी है। दोष अदृश्य है। [BLOCK_TYPE five_conditions/conditions_diagram]
Condition 3: Small-N मूल
[BLOCK_TYPE five_conditions/conditions_diagram]कोड विकास वातावरण में लिखा और समीक्षित किया जाता है। विकास ग्राफ़ में 50 नोड्स होते हैं। विकास अनुरोध लोड में 10 समवर्ती थ्रेड्स होते हैं। विकास कैश मिस दरें कम होती हैं (गर्म कैश, कुछ कुंजियाँ)। N=50 पर O(N²) लागत 2,500 ऑपरेशन है। अदृश्य। N=50,000 पर लागत 2,500,000,000 ऑपरेशन है। 1-सेकंड बिल्ड के बजाय 17-मिनट का बिल्ड। [BLOCK_TYPE five_conditions/conditions_diagram]
जिस लेखक ने कोड लिखा, उसने कभी N=50,000 नहीं देखा। जिस समीक्षक ने इसे स्वीकृत किया, उसने कभी N=50,000 नहीं देखा। दोष अपने लेखन के पैमाने पर दिखाई नहीं दिया। [BLOCK_TYPE five_conditions/conditions_diagram]
Condition 4: कॉपी संदर्भ के बिना फैलती है
एक सही एल्गोरिदम शिक्षाप्रद होता है। ट्यूटोरियल सही उदाहरणों से सिखाते हैं। डॉक्यूमेंटेशन काम करने वाला कोड दिखाता है। वही Tarjan SCC स्केलेटन — visited = [], अंदर if n not in visited — GHC, Maven, Python pip, Cargo, TypeScript कंपाइलर, Kotlin कंपाइलर, Scala कंपाइलर और javac में दिखाई देता है। अलग-अलग टीमें, अलग-अलग भाषाएँ, अलग-अलग दशक। वही जीवाश्म। मूल लेखक का N=50 कोड के साथ आगे नहीं बढ़ता। जो आगे बढ़ता है: सही आउटपुट। जो पीछे रह जाता है: प्रदर्शन की धारणा।
[BLOCK_TYPE SECTION/STEP]
Condition 5: फ्रोज़न कोड के आसपास स्केल बढ़ना
[BLOCK_TYPE SECTION/STEP]कोड खराब नहीं होता। इंफ्रास्ट्रक्चर स्केल करता है। 2003 में 200 पैकेजों के लिए लिखा गया डिपेंडेंसी रिज़ॉल्वर 2024 में 50,000 पैकेजों पर चलता है। कोई इसे दोबारा नहीं लिखता — यह काम करता है। कोई इसका प्रोफाइलिंग नहीं करता — CI हरा है। वह N जो O(N²) लागत को विनाशकारी बनाता है, धीरे-धीरे, अदृश्य रूप से, प्रोडक्शन स्केल पर आता है। तब तक मूल लेखक चला गया होता है। कोड एक डिपेंडेंसी बन चुका होता है। कोई काम करने वाली डिपेंडेंसी को छूता नहीं।
निदान: पाँच शर्तें
पाँच शर्तें: सही आउटपुट, कोई जटिलता परीक्षण नहीं, छोटे-N मूल, संदर्भ के बिना कॉपी, फ्रोज़न कोड के आसपास स्केल बढ़ना।
हर MOAD के लिए ये पाँचों शर्तें मौजूद थीं। यह संयोग नहीं है — यह एक सेडिमेंटरी डिफेक्ट क्लास का संरचनात्मक हस्ताक्षर है।
What Hamming Said
Richard Hamming के 1986 में Bell Labs में दिए गए व्याख्यान — जो 1997 में The Art of Doing Science and Engineering के रूप में प्रकाशित हुए — MOAD दोष पैटर्न का सीधा वर्णन करते प्रतीत होते हैं। वे MOAD का वर्णन नहीं कर रहे थे। वे इंजीनियरिंग प्रणालियों की उस संरचनात्मक प्रवृत्ति का वर्णन कर रहे थे जिसमें स्थानीय रूप से सही निर्णय वैश्विक रूप से महंगे हो जाते हैं।
Hamming जटिलता पर: 'The purpose of computing is insight, not numbers. But you have to have the right complexity of algorithm or the numbers will never come. An O(N²) algorithm that runs on N=100 will not run on N=1,000,000 before you retire.'
Hamming कॉपी पर: 'Great engineers do not just copy solutions. They understand why the solution works, under what conditions it holds, & what would break it. A copied solution without its conditions is a time bomb.'
Hamming परीक्षण पर: 'Testing what you measured is not the same as measuring what matters. We build elaborate test suites for the properties we chose to test. We leave untested the properties we did not choose. What we leave untested is what surprises us in production.'
Hamming on scale: 'The error you make in the first year of a project is the error you are still correcting in the tenth year. Early assumptions calcify. The project scales around them. Nobody rewrites the foundation.'
चेतावनी और क्रियान्वयन के बीच का अंतर
Hamming की चेतावनियाँ सही थीं। उन्हें पढ़ाया गया। उनका हवाला दिया गया। उन्हें पाठ्यक्रमों में शामिल किया गया। लेकिन चेतावनी एक डिटेक्टर नहीं होती। Hamming ने दोष के स्वरूप का वर्णन किया। उन्होंने ऐसा टूल नहीं बनाया जो CI में चलकर O(N²) हॉट पाथ्स, ThreadLocal आइडेंटिटी लीक, या क्रेडेंशियल लॉगिंग को फ्लैग करे। 'जानने योग्य' और 'पता लगाने योग्य' के बीच का अंतर सिद्धांत और उसके स्वचालित इंफ्रास्ट्रक्चर के रूप में क्रियान्वयन के बीच का अंतर है।
MOAD इसलिए अस्तित्व में है क्योंकि क्षेत्र ने सहीपन का इंफ्रास्ट्रक्चर तो बनाया, लेकिन प्रदर्शन या सुरक्षा का इंफ्रास्ट्रक्चर उसी स्तर पर नहीं बनाया। यूनिट टेस्ट: 1970 के दशक से मानक। प्रॉपर्टी-बेस्ड टेस्ट: 1990 के दशक से मानक। CI में एल्गोरिदमिक जटिलता बेंचमार्क: 2026 में भी अभी प्रयोगात्मक।
चेतावनी को क्रियान्वित करना
Hamming ने जटिलता के जमाव, अपरीक्षित गुणों, शर्तों के बिना कॉपी किए गए समाधानों, और स्केल द्वारा प्रारंभिक मान्यताओं को कुचलने के बारे में चेतावनी दी। उन्होंने हमें शब्दावली दी। उन्होंने हमें डिटेक्टर नहीं दिया।
MOAD पाइपलाइन इस अंतर को भरती है: स्कैन → टिकट → पैच → यूनिट टेस्ट → डिस्क्लोज़ → PR → अपस्ट्रीम मर्ज। यह क्रियान्वित Hamming है: केवल चेतावनी नहीं, बल्कि स्वचालित डिटेक्शन और फिक्स पाइपलाइन।
The Fester Signature
एक MOAD-क्लास दोष की एक पहचानने योग्य signature होती है। सभी पाँच शर्तें एक साथ मौजूद होती हैं। सभी पाँच को एक भी स्कैन लिखे बिना जाँचा जा सकता है:
1. सही आउटपुट? स्टैंडर्ड टेस्ट सूट चलाएँ। यदि पास हो जाता है, तो दोष एक performance या security प्रॉपर्टी है, न कि correctness वाली। इसका मतलब है कि स्टैंडर्ड CI इसे नहीं पकड़ेगा।
2. कोई जटिलता परीक्षण नहीं? CI कॉन्फ़िगरेशन जाँचें। क्या कोई बेंचमार्क स्टेज है? क्या यह केवल वॉल टाइम की बजाय एल्गोरिदमिक व्यवहार की तुलना पिछले कमिट से करता है? यदि नहीं: शर्त मौजूद।
3. छोटे-N मूल? git blame और मूल कमिट जाँचें। पहली इम्प्लिमेंटेशन में डेटासेट का आकार क्या था? क्या वह आकार वर्तमान प्रोडक्शन लोड से 100× से अधिक छोटा है? यदि हाँ: शर्त मौजूद।
4. कॉपी फैलती है? कोडबेस और विभिन्न इकोसिस्टम में पैटर्न खोजें। क्या वही संरचनात्मक पैटर्न N≥3 स्वतंत्र कोडबेस में बिना किसी साझा पूर्वज के दिखता है? यदि हाँ: फॉसिल फैल चुका है। प्रत्येक कॉपी: एक नया संक्रमण स्थल।
5. स्केल बढ़ता है? प्रोडक्शन मेट्रिक्स जाँचें। पहली डिप्लॉयमेंट के समय N क्या था और आज क्या है? क्या वृद्धि दर निरंतर बनी हुई है? किस N पर दोष ऑपरेशनल रूप से गंभीर हो जाता है?
यदि सभी पाँच जाँच लिए और पुष्टि हो जाएँ: आपके पास MOAD-क्लास दोष है। समाधान हमेशा एक-लाइन या एक-मेथड प्रतिस्थापन होता है। खोज कठिन भाग है। समाधान आसान भाग है।
यही Hamming का मतलब था: इंजीनियरिंग समाधान के बारे में नहीं है। समाधान एक बार दिखने पर सीधा होता है। इंजीनियरिंग उन सिस्टम्स को बनाने के बारे में है जो आपको इसे देखने देते हैं।
हस्ताक्षर लागू करें
MOAD संक्रमण हस्ताक्षर: सही आउटपुट + कोई जटिलता परीक्षण नहीं + छोटे-N मूल + कॉपी फैलती है + स्केल बढ़ता है।
यह हस्ताक्षर केवल पाँच MOAD दोषों तक सीमित नहीं है। यह दोषों के एक वर्ग का वर्णन करता है जो किसी भी सिस्टम में बना रहता है जहाँ केवल correctness परीक्षण ही स्वचालित गुणवत्ता गेट होते हैं।