सॉफ़्टवेयर प्रोडक्ट वास्तव में कैसे काम करते हैं, यह किसी को नहीं पता [अनुवादित लेख]

1. बड़े tech systems की अपारदर्शिता

• बड़ी tech कंपनियां अपने ही systems को "युद्धक्षेत्र की धुंध (fog of war)" के भीतर चलाती हैं।
• "क्या Y type user feature X का उपयोग कर सकता है?", "action Z होने पर ठीक-ठीक क्या होता है?", "मौजूदा pricing plans कितने हैं?" जैसे बुनियादी सवालों का जवाब भी अक्सर संगठन के भीतर केवल कुछ ही लोग दे सकते हैं।
• गंभीर स्थिति में जांच के लिए अलग से किसी को नियुक्त करना पड़ता है, जबकि केवल public documents देखकर ही जवाब मिल जाना चाहिए, पर ऐसा नहीं होता।

2. जटिलता की जड़: Wicked Features

• बड़ा software self-hosting, free trial, organization/policy controls, multilingual localization, regulatory compliance features आदि की वजह से बेहद जटिल हो जाता है। ऐसे features हर नए feature को प्रभावित करते हैं
• उदाहरण: policy control जोड़ने पर हर नए feature पर भी उसे बार-बार लागू करना पड़ता है, और localization होने पर translation भी साथ ले जाना पड़ता है।
• "EU region self-hosting enterprise customers को किसी खास feature की access है या नहीं" जैसी बात अक्सर केवल सीधे code की जांच या experiments से ही पता चलती है। ऐसे features छोड़ देने का मतलब बहुत बड़े revenue का त्याग है, और यही बड़ी व छोटी कंपनियों के बीच का अंतर भी है।

3. documentation की सीमाएं

• नए features के समय interactions का documentation करना सिद्धांततः संभव है, लेकिन system में बदलाव की रफ्तार documentation से तेज होती है।
• static system नहीं बल्कि dynamic environment में documentation लिखने वाले को बदलाव से आगे रहना पड़ता है, और यह लगभग असंभव है.
• इससे भी बड़ी समस्या यह है कि बहुत-सा behavior स्पष्ट intent की बजाय default settings की interactions से पैदा होता है — documentation करना मानो असली system की खोजबीन करने जैसा है।

4. जवाब का मूल: codebase और engineers

• सटीक जवाब आखिरकार सीधे codebase को देखकर ही मिलता है, और यही engineers की शक्ति का आधार है।
• engineering team का मुख्य काम है software से जुड़े सवालों के जवाब दे पाने की क्षमता
• किसी खास code के बारे में लोगों के दिमाग में रहने वाले tacit knowledge का उपयोग करना पड़ता है।
• team reorganization होने पर knowledge loss के कारण "exploratory surgery" (code बदलना / checks को मजबूर करना आदि) की जरूरत पड़ती है।
• code लिखना आसान हो सकता है, लेकिन विश्वसनीय जवाब देना confidence की समस्या के कारण कठिन है (गलत होने का जोखिम, और सारांश बनाकर संक्षेप में बताने की जरूरत)।

5. निष्कर्ष: एक बेहद मूल्यवान क्षमता

• गैर-तकनीकी लोग अक्सर मानते हैं कि software engineers के लिए पूरी तरह समझा हुआ होता है, लेकिन बड़े systems को कोई भी पूरी तरह नहीं जानता।
• बुनियादी सवालों के लिए भी बार-बार जांच करनी पड़ती है, और बदलाव होने पर बारीकियां व exceptions सामने आते हैं। सटीक जवाब देने की क्षमता बेहद मूल्यवान है।