आपको कभी यह नहीं सिखाया जाता कि गुणवत्तापूर्ण सॉफ़्टवेयर कैसे बनाया जाए

“गुणवत्तापूर्ण सॉफ़्टवेयर” का क्या मतलब है (और क्या इसे सिखाया जा सकता है)

• कई लोग तर्क देते हैं कि “गुणवत्ता” अस्पष्ट है: क्या यह विश्वसनीयता है, प्रदर्शन है, रखरखाव-योग्यता है, UX है, या व्यावसायिक मूल्य?
• कुछ का कहना है कि गुणवत्ता ज़्यादातर अभ्यास और फ़ीडबैक से सीखी जाती है, न कि कक्षा में पढ़ाए गए सिद्धांत से।
• अन्य लोग ज़ोर देते हैं कि एक शैक्षणिक और इंजीनियरिंग अनुशासन मौजूद है (सॉफ़्टवेयर इंजीनियरिंग, QA, फॉर्मल मेथड्स) जो गुणवत्ता सिखाता है, लेकिन उसका अपनाया जाना असमान है।

अन्य क्षेत्रों से तुलना (विमानन, विनिर्माण, इंजीनियरिंग)

• विमानन और विनिर्माण को ऐसे उदाहरणों के रूप में उद्धृत किया जाता है जहाँ गुणवत्ता चेकलिस्ट, नियमों, घटना-समीक्षाओं, और प्रक्रिया-नियंत्रणों के माध्यम से व्यवस्थित रूप से सिखाई जाती है।
• कुछ लोग सुझाव देते हैं कि सॉफ़्टवेयर के लिए 500-आइटम की एक समान चेकलिस्ट बग्स को काफ़ी कम कर देगी, लेकिन स्टार्टअप-शैली की गति को खत्म कर देगी।
• प्रति-तर्क: “कठोर” इंजीनियरिंग में भी दोष, रिकॉल, और विफलताएँ आम हैं; सब कुछ “काफ़ी अच्छा” होता है, परिपूर्ण नहीं।

यूनिवर्सिटी CS बनाम सॉफ़्टवेयर इंजीनियरिंग

• बार-बार शिकायत यह है कि CS कार्यक्रम एल्गोरिद्म, कम्पाइलर, सिद्धांत, और लो-लेवल सिस्टम्स पर ध्यान देते हैं, लेकिन QA, टेस्टिंग, डिबगिंग रणनीति, या बड़े पैमाने पर सिस्टम डिज़ाइन पर बहुत कम।
• अन्य लोग बताते हैं कि उन्होंने गंभीर सॉफ़्टवेयर इंजीनियरिंग कोर्स किए हैं: टेस्टिंग, SDLC, UML, टीम प्रोजेक्ट्स, कैपस्टोन्स जो वास्तविक दुनिया के रखरखाव का अनुकरण करते हैं।
• यह बहस भी है कि विश्वविद्यालयों को नौकरी-प्रशिक्षण होना चाहिए या शुद्ध शिक्षा, खासकर बढ़ती ट्यूशन और नौकरी की अपेक्षाओं को देखते हुए।

QA, टेस्टिंग, और प्रक्रिया

• एक मज़बूत विषय: QA अक्सर शेड्यूल के दबाव के कारण अंत में जोड़ दिया जाता है (या छोड़ दिया जाता है); “QA स्प्रिंट्स” और देर से टेस्टिंग को anti-patterns कहा जाता है।
• समर्थक यह सुझाते हैं: कोड के साथ-साथ लिखे गए टेस्ट, CI/CD, ऑटोमेशन, स्नैपशॉट/विज़ुअल टेस्ट, कवरेज के साथ म्यूटेशन/फ़ज़ टेस्टिंग, और सोच-समझकर मेट्रिक्स (Goodhart’s law की समझ के साथ)।
• कुछ लोग नोट करते हैं कि उच्च-गुणवत्ता वाली टीमें मौजूद हैं जहाँ प्रयास का 40–60% टेस्टिंग और गुणवत्ता कार्य में जाता है, लेकिन वे सामान्य नहीं हैं।

बग्स, “बग-फ्री” दावे, और फॉर्मल मेथड्स

• सहमति: तुच्छ प्रोग्रामों से परे पूर्णतः बग-फ्री सॉफ़्टवेयर व्यावहारिक रूप से असंभव है; “zero bugs” को बेहतर रूप से एक asymptote या “spec के विरुद्ध कोई ज्ञात दोष नहीं” के रूप में देखा जाता है।
• “बग” की परिभाषाओं पर बहस है (spec से विचलन बनाम कोई भी अप्रत्याशित व्यवहार) और क्या spec की त्रुटियाँ गिनी जाती हैं।
• फॉर्मल मेथड्स और प्रूफ सुरक्षा-महत्वपूर्ण क्षेत्रों में दोषों की श्रेणियों को समाप्त कर सकते हैं, लेकिन वे महँगे, सीमित-क्षेत्रीय, और खराब या अधूरे विनिर्देशों को ठीक नहीं करते।

अर्थशास्त्र, प्रोत्साहन, और समझौते

• कई लोग बताते हैं कि प्रबंधन अक्सर गुणवत्ता की तुलना में गति और दिखाई देने वाली विशेषताओं को प्राथमिकता देता है, क्योंकि व्यावसायिक मेट्रिक्स शायद ही लंबे समय की रखरखाव-योग्यता को पुरस्कृत करते हैं।
• गुणवत्ता की लागतें फैली हुई और विलंबित होती हैं (तकनीकी ऋण, धीमी टीमें, उपयोगकर्ता का बर्बाद समय), जबकि विकास लागत तुरंत और मापने योग्य होती है।
• कुछ का तर्क है कि बड़े पैमाने पर “दुर्लभ” बग्स भी आम हो जाते हैं और “a thousand cuts” से मृत्यु” का कारण बनते हैं, लेकिन अन्य कहते हैं कि अधिकांश बाज़ार घटिया सॉफ़्टवेयर को सह लेते हैं यदि वह तेज़ी से शिप हो और कोई समस्या हल करे।