गलती से भार संभालने वाली चीज़

• जो structures या code पहले मामूली या अस्थायी लगते थे, वे भी समय के साथ system को सहारा देने की भूमिका निभा सकते हैं, इसलिए बदलाव से पहले मौजूदा dependencies तक की जाँच करनी चाहिए
• Chesterton's Fence हटाने से पहले यह समझने का उपयोगी सिद्धांत है कि उसे लगाया क्यों गया था, लेकिन केवल शुरुआती इरादे को देखने पर बाद में बनी भूमिकाएँ छूट सकती हैं
• घर के bathroom renovation के दौरान बाधा जैसी दिख रही vertical stud closet partition का उद्देश्य खत्म होने के बाद भी, गलत structural बदलावों की वजह से दूसरी मंज़िल का कुछ भार संभाल रही थी
• जटिल computer systems में भी change history और design documents सिर्फ शुरुआती बिंदु हैं; यह भी देखना चाहिए कि कोई component अभी system में कैसे integrate है
• पुराने component को हटाते या संशोधित करते समय, अगर पुराने design reason और मौजूदा छिपी भूमिका दोनों की जाँच न की जाए, तो अप्रत्याशित failures हो सकते हैं

---

Chesterton's Fence क्या चूक सकता है

• Chesterton's Fence यह विचार है कि किसी चीज़ को बदलने या हटाने से पहले पहले यह जानना चाहिए कि वह क्यों बनाई गई थी
• fence या door जैसी इंसानों द्वारा बनाई गई चीज़ों के पीछे आमतौर पर यह संभावना होती है कि किसी ने उसे किसी के लिए उपयोगी समझकर बनाया था
• कोई design पूरी तरह बेकार दिखे, तब भी बदलाव करने वाला व्यक्ति समस्या के किसी पहलू को चूक रहा हो सकता है
• लेकिन यह नज़रिया हमें मूल निर्माता द्वारा सोची गई भूमिका पर ही केंद्रित कर सकता है, जिससे बाद में बनी नई dependencies अनदेखी रह सकती हैं

घर की मरम्मत में मिला अनजाने में बना load support

• कुछ साल पहले घर का bathroom फिर से बनाते समय काम में बाधा डाल रही एक vertical stud थी
• वह stud मूल रूप से closet partition का हिस्सा थी, और closet partition की भूमिका अब ज़रूरी नहीं लग रही थी
• सिर्फ Chesterton's Fence के नज़रिए से देखें तो उसे हटाना ठीक लगता था, लेकिन असल में समय के साथ वह भार संभालने वाली structure बन चुकी थी
  • दूसरे गलत structural बदलावों के दौरान यह stud घर की दूसरी मंज़िल को सहारा देने में योगदान दे रही थी
• कोई चीज़ शुरुआत में क्यों बनाई गई थी, सिर्फ यह नहीं, बल्कि बाद में उसने कौन-सी अतिरिक्त भूमिकाएँ निभानी शुरू कीं, यह भी जाँचना चाहिए

जटिल computer systems पर लागू होने वाला सबक

• जटिल computer systems बदलते समय भी यही समस्या दोहराती है
• change history देखना, मूल design documents पढ़ना, और यह समझना कि कोई specific component उस तरह क्यों बनाया गया था, अब भी उपयोगी है
• लेकिन सुरक्षित रहने के लिए यह भी देखना ज़रूरी है कि वह component अभी system के भीतर किस तरह connected और used है
• components समय के साथ अपने मूल उद्देश्य से अलग secondary roles निभाने लगते हैं
• सुरक्षित बदलाव की शुरुआत पुराने design intent और मौजूदा वास्तविक भूमिका, दोनों को साथ में जाँचने से होती है

[GN⁺]

Hacker News की राय

• आखिरकार ऐसा लग रहा है कि इसे पुकारने के लिए कोई नाम मिल गया
  मैं control systems support का काफी काम करता हूँ, और ऐसा कम नहीं होता कि किसी physical equipment को अजीब तरीके से संभालने वाला PLC code अनचाही समस्याएँ पैदा कर दे
  “हर बार जब software से electrical/mechanical समस्या ठीक की जाती है, एक gremlin पैदा होता है” — यह बात मुझे अक्सर दोहरानी पड़ती है
  अगर किसी bug की root cause या कोई programmed restriction मिल भी जाए जिसे हटाना चाहता हूँ, तो जब तक यह न जान लूँ कि वह code वहाँ क्यों है, हमेशा मना कर देता हूँ। कोई code बिना वजह नहीं डाला गया होता, इसलिए पहले यह समझना ज़रूरी है कि timer या override की ज़रूरत क्यों पड़ी
  कई बार अच्छी बात यह होती है कि वह code किसी ऐसी समस्या को हल कर रहा था जो अब मौजूद नहीं है, लेकिन अक्सर ऐसा भी होता है कि किसी accident को रोकने के लिए code डाला गया था और staff बदलने के साथ उसका असली उद्देश्य खो गया। Documentation न हो तो किसी और के काम को तुरंत revert करने में मैं बहुत सावधान हो जाता हूँ
  इसमें सहकर्मियों पर भरोसे की बात भी है। आम तौर पर लोग बिना वजह कुछ नहीं करते, इसलिए अगर code मौजूद है तो मानना चाहिए कि उसका कोई उद्देश्य है और शुरुआत में उसकी पर्याप्त समीक्षा हुई होगी। जब वह भरोसा टूट जाता है, तो हर decision मुश्किल हो जाता है

  • इसलिए जो code line बहुत obvious नहीं होती, उसमें मैं हमेशा comment में क्यों ऐसा है लिखता हूँ
    अगर कारण codebase के बाहर की चीज़ों—operating system, filesystem, database, HTTP endpoint, hardware—से interaction है, तो simple API या library call न हो तो मैं 100% comment छोड़ता हूँ
    अगर किसी दूसरी service की rate limit की वजह से sleep डाला है, तो लिखता हूँ कि यह किसकी requirement है, उस समय जितनी जानकारी थी उसके हिसाब से limit क्या थी, अगर ठीक-ठीक नहीं पता तो “अनुमान है, लेकिन काम करता दिख रहा है”, और limit पार होने पर system कैसा दिख सकता है
    अगर कोई छोटी-सी चीज़ filesystem से भी हो सकती थी लेकिन database इस्तेमाल किया जा रहा है, और असल में उस environment में ज़रूरी तरीके से filesystem access करने पर load में system calls की बाढ़ से resources खत्म हो जाते हैं, तो comment छोड़ता हूँ
    Ubuntu के LTS release में ठीक न किए जाने वाले किसी widely used library bug के workaround पर भी comment जरूरी है। “मुझे पता है यह अच्छा नहीं है, लेकिन वजह यह है” जैसे comments मैंने सचमुच बहुत लिखे हैं
    जब अभी scalable तरीके से बनाना झंझट लगता है और मौजूदा अनुमान से ज़रूरत भी नहीं है, लेकिन ऐसा code लिख रहा हूँ जो बड़े scale पर ठीक नहीं चलेगा, तब भी comment छोड़ता हूँ। शायद यह ego बचाने जैसा है, लेकिन कुछ ऐसा: “मुझे पता है कि पूरा file memory में पढ़ रहा हूँ, लेकिन यह rare और predictable batch job है और file भी छोटी रहने वाली है, इसलिए ठीक है। Memory कम पड़े तो पहले यहाँ देखें। इसे on-demand call में बदलना हो तो दोबारा लिखें”
  • मुझे लगता है यह बस सामान्य Chesterton's fence वाली logic है
    लेख जिस बात की ओर इशारा कर रहा है, वह यह है कि यह अपने-आप में पर्याप्त नहीं है। क्योंकि यह भी जानना ज़रूरी है कि उस code के मौजूद होने की assumption पर और क्या बनाया गया है
  • Allen Bradley PLC की गहराई में मैंने जो सबसे डरावना comment देखा था, वह यह था
    “मुझे नहीं पता यह rung क्यों ज़रूरी है, लेकिन इसे हटाकर खुद देख लो”
    मैंने बेवजह छेड़ा नहीं, और जाँचने की कोशिश भी नहीं की
  • इसका कुछ हिस्सा cultural भी है
    Electrical engineers और mechanical engineers ऐतिहासिक रूप से software को electrical/mechanical systems जितनी गंभीरता से नहीं देखते रहे हैं, और नतीजतन EE/ME-dominated engineering culture में खराब code निकलना आसान है
    बाहर से Professional Engineer दिखने वाले लोगों के बीच भी अस्वीकार्य रूप से अपरिपक्व software engineering अब भी आम है
  • शायद मैं PLC का काम फिर कभी नहीं करूँगा
    बिना documentation वाले code को छोड़ भी दें, तो अक्सर hardware 30 साल पहले का custom-made होता है, इसलिए जिस equipment पर काम कर रहे हैं उसका circuit diagram तक नहीं होता

• मेरे साथ भी कुछ ऐसा ही हुआ था
  कुछ साल पहले मैंने एक पुराना घर खरीदा, और पिछले owners 1960s से ज़्यादातर काम खुद ही करते आए थे
  zinc gutter शायद दशकों तक leak होता रहा और roof structure के कुछ हिस्से खराब कर गया, और roof को 70s में अंदरूनी हिस्सा ढकने के लिए लगाए गए wood panels सहारा दे रहे थे। यानी वे wood panels सच में load उठा रहे थे
  इस घर में मुझे इससे भी बहुत कुछ मिला। उदाहरण के लिए, roof के edge पर tiles की width कम पड़ गई तो extra tiles खरीदने के बजाय cement और टूटे ceramic flower pot के टुकड़ों से भर दिया गया था

  • अगर 1900s की शुरुआत तक जाएँ, तो exterior material को diagonal लगाया जाता था, जिससे building के मुड़ने/टेढ़ा होने को काफी हद तक रोका जाता था
    आजकल earthquakes और storms में उस भूमिका के लिए gypsum board और plywood पर भरोसा किया जाता है
    जब आप किसी घर को सिर्फ frame तक strip करके rebuild करते देखेंगे, तो कुछ extra bracing जोड़ी हुई दिखेगी। यह walls को गिरने से रोकने के लिए नहीं, बल्कि walls फिर से खड़ी होने तक right angle और plane बनाए रखने के लिए होती है
  • मेरा garage भी बिल्कुल ऐसा ही लगता है
    पहली नज़र में लगता है किसी ने garage door को टक्कर मारकर बुरी तरह मोड़ दिया है, लेकिन ध्यान से देखने पर पता चलता है कि roof बस मुश्किल से उस rail पर टिका है जिस पर door लगा है, और लगभग खत्म होने की कगार पर है
    शुरुआत में मैं rafters के सिरों को जोड़कर, और यह सोचकर कि पहले किसी ने दूसरी तरफ भी ऐसा किया था तो चल जाएगा, सिर्फ garage door बदलना चाहता था, लेकिन अब लगता है पूरी roof नई करनी पड़ेगी
    असली चिंता basement में फैली संदिग्ध wiring है। अपेक्षाकृत नई wires, पुरानी cloth-insulated wires, और उन्हें जोड़ने वाली electrical tape सब मिली-जुली हैं। शुक्र है, wires में से कोई भी load-bearing नहीं लगती
  • load-bearing paint तक बस कुछ ही कदम बचे हैं
  • एक घर था जिसमें termite damage बहुत ज्यादा था, और contractor ने उसे structural stucco कहा

• मुझे लगता है कि यह लेख और लगभग सभी comments असली समस्या को miss कर रहे हैं। मुख्य बात testing की कमी है
  software, production के बाकी सभी साधनों से अलग, बदलावों को reality में लागू करने से पहले वास्तव में test कर सकता है
  अगर अच्छे tests हों, तो इरादा क्या था, उस feature का कोई नया use या नया user बना या नहीं—इससे फर्क नहीं पड़ता। fix करो और tests चलाओ, वे बता देंगे कि वह fix अच्छा है या नहीं
  अच्छे tests हों तो software archaeology, हर crack को जानने वाले seasoned veteran, जटिल system को दिमाग में model करने वाले prodigy, comprehensive requirements document, या कुछ user groups को guinea pig बनाने वाले सावधान deployment system की जरूरत नहीं होती
  अच्छे tests हों तो आप system को random तरीके से बदलते हुए improvement आने पर रुक भी सकते हैं। ठीक उसी तरह जैसे Google ने report किया कि AI ने alignment improvement “develop” किया
  फिर भी test developers को आधे से भी कम pay मिलता है, test departments अपेक्षाकृत छोटे होते हैं, QA fixed और सीमित schedules में दबा रहता है, और QA background वाले technical heroes लगभग नहीं मिलते। शायद इसलिए कि यह derivative और reactive काम जैसा दिखता है

  • भले ही tests उस behavior को verify करते हों जिसके लिए code design किया गया था, ऐसे cases होते हैं जहाँ दूसरे systems code के वास्तव में किए जाने वाले behavior पर depend करने लगते हैं
    आपने unused code और उसके tests हटा दिए, लेकिन असल में वह अब भी इस्तेमाल हो रहा हो सकता है
    बदलाव के बाद test fail हुआ, लेकिन test fragile था इसलिए नई स्थिति के हिसाब से test ठीक कर दिया; बाद में पता चला कि कोई चीज पुराने behavior पर depend कर रही थी
    tests बेहतरीन हैं, और काफी self-contained systems में वे अकेले पर्याप्त हो सकते हैं। लेकिन बड़े systems में कभी-कभी telemetry या phased rollout भी चाहिए होता है
  • tests का एक specific scope होता है। वह scope जिसके लिए code जिम्मेदार है; यह जरूरी नहीं कि महीनों या सालों के use के दौरान उससे अब अपेक्षित हर काम को cover करे
    मूल code खरीदारी सूची का VAT calculate करने के लिए था, लेकिन धीरे-धीरे वह product category के हिसाब से VAT cache को force refresh करने का तरीका बन सकता है और ऐसे context में call हो सकता है जिसकी शुरुआत में उम्मीद नहीं थी
    comments के साथ भी यही है। वे original intent और side effects को cover करते हैं, लेकिन बहुत बाद में वह method या class कहाँ इस्तेमाल हो रही है, या वास्तव में क्या करने लगी है, यह नहीं बता पाते
    ideal दुनिया में जब आसपास की दुनिया बदलती है तो comments भी update होते हैं, लेकिन व्यवहार में जब तक internal code साथ में नहीं बदलता, ऐसा लगभग कभी नहीं होता
  • बहुत लंबे समय तक चलने वाले projects पर काम करें तो tests या अच्छी budget वाली QA भी organizational problems को रोक नहीं पाते
    आम तौर पर tests सड़ने लगते हैं। लगता है जैसे tests की भी expiry date होती है, और आखिरकार कुछ tests मरने लगते हैं
    dependency issues, API expectations में बदलाव, security updates, accounts और credentials expire होना, machine endpoints और state changes—इन सबके mix से test results अब program की correctness नहीं दिखा पाते
    किसी एक टूटे test को ठीक करने की marginal business value आम तौर पर बहुत कम होती है, इसलिए उसे पूरी तरह बंद कर देना या जहाँ error होना चाहिए वहाँ भी उसे “pass” करने के लिए force करना आम है
    10, 20 साल तक ऐसा दोहराने पर जल्दी ही “वे tests जिन पर सच में भरोसा है” और “वे tests जिन्हें ठीक या साफ करने की फुर्सत नहीं” अलग हो जाते हैं
    कौन सा test अच्छा है और कौन सा खराब, यह tribal knowledge बन जाता है जो job और role changes के साथ गायब हो जाता है, और किसी point पर “ऐसे tests जो झूठ बोलते हैं कि वे काम कर रहे हैं” और “ऐसे tests जिनकी failure सच है या नहीं, यह अब कोई नहीं पूछता” का पूरा ढेर ही अनजाने में load-bearing बन जाता है
  • शुरुआत में यह test-driven development वाली optimism दोहराने जैसा लग रहा था, लेकिन अचानक test department की बात पर चला गया, इसलिए consistency कम हो गई
    बेहतर होगा कि कहा जाए कि programmers को tests लिखने चाहिए, उन्हें code के साथ रखना चाहिए, और build process में automatically चलाना चाहिए
    लेकिन मेरा मानना है कि proper test-driven development भी अच्छी design और अच्छे practices की जगह नहीं ले सकता। बहुत simple specification को भी tests से replace नहीं किया जा सकता
    अगर f(S) की specification सिर्फ इतनी है कि वह string को खुद से concatenate करके return करता है, तो f को black box मानकर obvious tests से यह verify करना मुश्किल है कि f सही है। formal specification भी जरूरी है
    कुछ जगह sample कर सकते हैं, लेकिन अगर magic तरीके से एक गलत value भी critical हो, तो test वह नहीं दिखा पाएगा
    software archaeology, seasoned veterans, system को दिमाग में model करने वाले prodigies, comprehensive requirements documents, कुछ users को guinea pig बनाने वाले deployment systems—इनका मजाक बनाया जा सकता है, लेकिन ये सब इसलिए बने हैं क्योंकि software कठिन है। और software सच में कठिन है
  • test developer, test department, QA team जैसी अलग-अलग categories खुद ज्यादातर software organizations के लिए luxury जैसी हैं
    आम तौर पर software teams को अपने काम की quality की सीधी जिम्मेदारी लेनी पड़ती है, और वे org chart के पार problem नहीं फेंक सकतीं

• यह समझ आता है कि जो stud पहले अहम नहीं था, बाद में load लेने लगा, लेकिन मेरे अनुभव में यह आलसी design का संकेत जैसा दिखता है
  कम-से-कम software बनाते समय यह पता चल सकता है कि आप सजावटी stud से घर के किसी हिस्से को टिकाने की कोशिश कर रहे हैं, और अगर बेहतर नई structure बनाए बिना बस ऐसा ही करने का फैसला लेते हैं, तो बाद में development team काफी उदास हो जाती है
  लेख से सहमत हूं, लेकिन ऐसी जगह काम करना कहीं बेहतर है जहां आप उम्मीद कर सकें कि ऐसी खोजें बार-बार नहीं होंगी

  • “आप” ने जो बनाया है उसमें “आप” जान सकते हैं, लेकिन मेरे career में दूसरों की बनाई चीजों को संभालना और फिर से बनाना कहीं ज्यादा रहा है
    इस लेख का point यह नहीं है कि सजावटी stud को load-bearing element की तरह इस्तेमाल न करें, बल्कि यह पहचानना है कि आपके आने से पहले किसी ने ऐसा किया हो सकता है
    यह Chesterton’s fence की basic interpretation से भी ज्यादा conservative रुख है, और उस basic interpretation को भी बहुत से लोग जरूरत से ज्यादा restrictive कहकर खारिज कर देते हैं
    मेरे लिए यह लेख resonate करता है। Programming के लिहाज से, मैंने सचमुच “decorative” molding हटाई और ceiling मेरे सिर पर गिर पड़ी, ऐसा अनुभव किया है
  • क्या यह हमेशा खराब अर्थ वाली आलस है? Software में “load लेने के लिए बनाई गई चीज” और “drywall लगाने के लिए बनाई गई चीज” के बीच कोई तीखी रेखा नहीं होती
    System robust है या खतरनाक रूप से unscalable, यह context पर निर्भर करता है
    “अगर sales team दोगुनी हो जाए और market का 100% कब्जा करने तक customers को जितनी जल्दी हो सके बेचकर onboard करे तो?” जैसे thought experiment हमेशा किए जा सकते हैं, और ऐसी स्थितियों में भी database को message queue की तरह इस्तेमाल करना ठीक हो सकता है
    अगर नतीजे में development team की हालत खराब हो गई, तो वह गलती का मामला है। यानी maintenance मुश्किल हो गया या operations नरक बन गया
    लेकिन software के सजावटी stud को load-bearing element की तरह इस्तेमाल करने से जरूरी नहीं कि हमेशा यही नतीजा निकले। कई systems ऐसे होते हैं जो proper solution बनाने के कई महीने बचाते हुए, चुपचाप खुशी-खुशी अपना काम करते रहते हैं
  • मान लें कि आप defensive तरीके से code लिखते हैं। Function में invalid input handling जोड़ते हैं
    Codebase का बाकी हिस्सा कभी invalid input नहीं भेजता, इसलिए वह branch dead code है और load नहीं लेती
    फिर किसी समय bug आ जाता है और invalid input भेजता है, और वह branch ईमानदारी से उसे handle करके recover करती है। उसी पल वह branch load-bearing branch बन जाती है
  • मैंने कभी सोचा था कि मैं एक गैर-महत्वपूर्ण service ठीक से चला रहा हूं, लेकिन outage होने पर पता चला कि जिस situation में असल में कुछ भी नहीं होना चाहिए था, किसी दूसरी team ने उसे business-critical functionality के लिए depend करना शुरू कर दिया था
  • मैंने ज्यादा बार यह देखा है कि ऐसी चीजें इसलिए होती हैं क्योंकि असल में किसी को यह पता ही नहीं होता

• मेरे देखे “अनजाने में load-bearing” artifacts में मेरा पसंदीदा गलत configure किया हुआ sudo था
  find command के लिए password-less sudo allow था, जिससे -exec के जरिए root privileges के साथ arbitrary code execution आसान हो जाता था, और product की कई अहम support scripts उसी का इस्तेमाल करने के लिए लिखी गई थीं
  एक तरह से यह load-bearing privilege escalation था

• कुछ साल पहले हमने kitchen remodel किया था
  पुराने kitchen के एक छोर पर एक बड़ा beam जा रहा था, जिसे हमारे घर खरीदने से पहले किसी remodel में दूसरी मंजिल जोड़ने के लिए लगाया गया था। Kitchen expand करने के लिए इसे हटाना जरूरी था
  Ceiling हटाकर देखा तो वह beam उस जगह से करीब 2 feet दाईं ओर था जहां उसे ऊपर वाली floor की wall को support करना चाहिए था
  आखिरकार इसे ठीक किया और beam को ऊपर वाली wall के अंदर move कर दिया, और सब ठीक हो गया, लेकिन जब original position के बारे में पूछा तो contractor ने लगभग ऐसा कहा
  “एक व्यक्ति था जो इसे सही करना चाहता था और एक व्यक्ति था जिसे परवाह नहीं थी। Quality आखिरकार सबसे कम setting पर ही settle होती है”

• Software की physical systems पर एक अच्छी बात यह है कि intent को ज्यादा साफ करने के लिए code में comments और types से आसानी से document किया जा सकता है
  खासकर Python जैसी dynamic languages में यह perfect नहीं है, लेकिन बहुत मदद करता है
  Load-bearing stud का analogy वह hackathon project हो सकता है जिसके production में जाने की उम्मीद नहीं थी
  असल में हमारा बहुत सारा काम किसी चीज को बस चलने लायक होने तक hack करना और फिर अगले काम पर बढ़ जाना होता है

  • सही है। Aerospace और defence में systems engineering ठीक इन्हीं समस्याओं की वजह से आई थी
    क्योंकि maintenance plan को यह जानना होता है कि हर replaceable part या assembly कौन-सा “load” ले रही है
    आज की systems engineering दुर्भाग्य से अपने original goal से बहुत दूर भटक गई है, लेकिन मूल सोच यही थी
    आज systems engineering departments की ताकत अपेक्षाकृत कम होने का एक कारण यह है कि maintenance planning में finance आ गया है। Inventory depreciation बेरहम होता है, और “spare के तौर पर क्या रखना है” कम-से-कम मेरे अनुभव में अब systems engineering का judgement शायद ही होता है
    नतीजा अनुमानित है, लेकिन aerospace maintenance staff का standard बहुत ऊंचा होना इसे कुछ हद तक offset करता है। उदाहरण के लिए, washing machine repair करने वालों की तुलना में ये काफी बेहतर होते हैं
    बेशक finance उस standard को भी कुछ level नीचे लाना चाहता है
  • अगर intentional हो तो ऐसा करना आसान है
    लेकिन मैं हमेशा हैरान होता हूं कि कितनी बार कोई upstream component जो “decorative” दिखता है, असल में speed limit लगा रहा होता है, और उसे हटाने पर बाकी system runaway हो जाता है

• मुझे वे cases याद आते हैं जब users software के bug का अनजाने में फायदा उठाकर उसे अपने normal workflow में शामिल कर लेते हैं
  नतीजतन bug fix करने पर workflow टूट जाता है और शिकायतें आती हैं

  • https://xkcd.com/1172/

• “यह आसानी से पता चल गया कि वह वहां क्यों था। वह closet partition का हिस्सा था” कहा गया, लेकिन समय के साथ वह अनजाने में load लेने लगा, और दूसरे गलत structural changes के जरिए वह stud अब घर की दूसरी मंजिल को support करने में मदद कर रहा था
  लेकिन साफ है कि यह आसानी से पता नहीं चला था कि वह वहां क्यों था। और मैं इस बात से भी convinced नहीं हूं कि वह अनजाने में load-bearing बना
  काफी संभव लगता है कि उसे ऐसे कारणों से जानबूझकर load-bearing बनाया गया हो जो आपको गलत लगते हैं, लेकिन उस समय के लोगों को गलत नहीं लगे होंगे

  • यह पता चल सकता था कि वह वहां क्यों था
    बस यह जानना कि वह शुरू में क्यों था, यह नहीं बताता कि वह अभी क्या कर रहा है

• पहले मेरे साथ काम करने वाले एक physics postdoc कभी-कभी equipment configuration पर ऐसा sign लगा देते थे
  “मत छुएं। छिपा हुआ खतरा है”
  Lab में smart लोगों की भरमार थी, और वे किसी चीज को देखकर यह खुद rationally conclude करने के आदी थे कि उसे बदलना ठीक है या नहीं
  यह sign ऐसे judgement में बहुत जल्दबाजी न करने की warning था