"Best practices" का पालन करने वाले कोड की तुलना में खराब वैज्ञानिक कोड बेहतर होता है (2014)
Scientific research often relies on quick, one-off scripts written by domain experts, while professional developers tend to bring heavier “best practices” and abstractions—even to small, experimental codebases. Commenters argue over which is worse: brittle, undocumented scientific code that undermines reproducibility, or over‑engineered systems that are hard to understand, modify, and adapt to evolving research questions. Many conclude the real issue is incentives and context, calling for a balance between simplicity and engineering discipline and for dedicated research software engineers to bridge the gap.
लेख पर समग्र प्रतिक्रिया
- कई लोगों को यह पोस्ट एक rant या strawman लगती है: इसमें “खराब वैज्ञानिकों का कोड” बनाम “खराब प्रोग्रामरों का कोड” को चरम उदाहरणों के साथ आमने-सामने रखा गया है।
- दूसरों का कहना है कि यह बहुत गहराई से प्रतिध्वनित होती है, खासकर over‑engineering और cargo‑cult “best practices” की आलोचना।
- कई लोग तर्क देते हैं कि असली निशाना “खराब प्रोग्रामर” होने चाहिए (अक्सर junior या pattern-cargo-cult करने वाले), न कि software engineering पूरे रूप में।
वैज्ञानिक बनाम software engineers
- आम धारणा: वैज्ञानिक अक्सर under‑engineer करते हैं (गंदा, ad‑hoc, एक बार इस्तेमाल होने वाले scripts); software engineers अक्सर over‑engineer करते हैं (abstraction की परतें, inheritance, “enterprise” patterns)।
- कुछ का कहना है कि वैज्ञानिक अपने domain में अक्सर अधिक समझदार होते हैं और one‑off tools के लिए अधिक प्रभावी हो सकते हैं; दूसरों का जवाब है कि domain intelligence, software skill का विकल्प नहीं है।
- कई commenters नोट करते हैं कि व्यवहार में scientific code का बहुत बड़ा हिस्सा buggy, unreproducible होता है, और अक्सर एक साल बाद चलता भी नहीं।
Overengineering, “best practices”, और complexity
- निम्नलिखित की कड़ी आलोचना की गई:
- अत्यधिक abstraction (deep inheritance, plugin systems, बहुत सारी छोटी files, indirection layers)।
- pattern-driven design (“Clean Code” को शाब्दिक रूप से लेना, micro-functions, फैले हुए module graphs)।
- Enterprise Java / heavy OOP, जिन्हें अनावश्यक complexity के ऐतिहासिक स्रोत माना गया।
- विपरीत दृष्टिकोण: ये best practices के दुरुपयोग हैं, खुद practices नहीं; अच्छा engineering सबसे सरल ऐसे design का लक्ष्य रखता है जो दीर्घकालिक बदलावों को सह सके।
Scientific code में समस्याएँ
- बार-बार दिखने वाली समस्याएँ: tests नहीं, version control नहीं, hard-coded paths और data, undocumented build steps, hardware का गलत उपयोग (जैसे सभी data को RAM में लोड करना)।
- reproducibility को व्यापक रूप से खराब माना जाता है; कुछ लोग कहते हैं कि यही replication crisis की जड़ है।
- दूसरे ध्यान दिलाते हैं कि अपेक्षाएँ अलग होती हैं: academia ने ऐतिहासिक रूप से “manual” reproducibility प्रयासों को स्वीकार किया, न कि button दबाते ही rerun होने वाली व्यवस्था को।
Imperial College COVID model उदाहरण
- कई पोस्ट इसे एक चेतावनी भरी कहानी के रूप में इस्तेमाल करती हैं: बड़ा, लंबे समय तक चलने वाला scientific code जिसमें गंभीर bugs थे (non-determinism, memory issues, fragile design) ने कथित रूप से नीति-संबंधी भ्रामक परिणाम दिए।
- इसे इस बात के प्रमाण के रूप में उद्धृत किया जाता है कि “quick and dirty” research code, जब वास्तविक दुनिया के निर्णयों के लिए पुनः उपयोग होता है, खतरनाक हो सकता है।
Collaboration और भूमिकाएँ
- बहुत से लोग समर्पित “research software engineers” की वकालत करते हैं, जो domain expertise और engineering discipline के बीच पुल का काम करें।
- domain experts को maintainability पर केंद्रित developers के साथ जोड़ना आदर्श माना जाता है, लेकिन इसके लिए धन कम है; academia में incentives robust software की बजाय papers को प्राथमिकता देते हैं।