यह किया जा सकता है (2003)
André Bensoussan द्वारा एक जटिल Multics file-system component को पूरी तरह कागज़ पर डिज़ाइन करने की कहानियाँ इस पर व्यापक बहस छेड़ती हैं कि सॉफ़्टवेयर को कैसे — और क्या आज भी — गहरे फोकस, स्पष्ट आवश्यकताओं, और न्यूनतम टूलिंग के साथ बनाया जा सकता है। टिप्पणीकार उस दौर के शांत कार्यालयों, अवधारणात्मक रूप से छोटे लेकिन कठिन सिस्टमों, और मजबूत डोमेन महारत की तुलना आज के interrupt-driven workflows, “agile” के तहत बदलती स्पेसिफिकेशन्स, और खराब दस्तावेज़ीकृत dependencies के फैले हुए stacks से करते हैं। कई लोग सावधानीपूर्वक upfront design, domain experts के साथ करीबी सहयोग, और लिखित design docs को कम आंका गया कौशल मानते हैं जो आधुनिक software quality को काफी बेहतर बना सकते हैं, भले ही वे बाधाएँ अब मौजूद न हों जिन्होंने कभी ऐसी rigor को मजबूर किया था.
कागज़-कलम प्रोग्रामिंग और ऐतिहासिक संदर्भ
- कई लोग बहुत सीमित कंप्यूटर पहुंच के साथ सीखने या काम करने को याद करते हैं (कागज़, पंच कार्ड, हफ्तों लंबे कंपाइल चक्र)।
- इससे सावधानीपूर्वक तर्क, कम पुनरावृत्तियाँ, और अक्सर ऐसा कोड बनता था जो पहली ही रन पर काम कर जाता था।
- कई लोग Multics की कहानी को एक व्यापक “दो बार नापो, एक बार काटो” युग का हिस्सा मानते हैं, जब कंप्यूट समय दुर्लभ था और टर्मिनल्स ध्यान भटकाने वाले नहीं होते थे।
- अन्य लोग नोट करते हैं कि यह शायद एक छँटनी भी थी: केवल अत्यधिक प्रेरित लोग ही उन बाधाओं के तहत टिके रहते थे।
आवश्यकताएँ, एज केस और बदलती स्पेसिफिकेशन्स
- स्पष्ट, स्थिर आवश्यकताओं और अच्छी तरह परिभाषित APIs के साथ उच्च-गुणवत्ता वाला कोड बनाना कहीं अधिक संभव हो जाता है, इस पर मजबूत सहमति है।
- आधुनिक समस्याएँ: अस्पष्ट लक्ष्य, देर से मिलने वाली स्टेकहोल्डर प्रतिक्रिया, “agile” कहकर लगातार स्कोप परिवर्तन, और समय-सीमाओं तथा “velocity” का दबाव।
- agile पर बहस: कुछ कहते हैं यह अपरिहार्य आवश्यकता परिवर्तनों का उत्तर है; दूसरे कहते हैं यह निरंतर उथल-पुथल को सामान्य बनाता है और गैर-जिम्मेदाराना बदलाव को बढ़ावा देता है।
- एज केस बग्स और जटिलता का बड़ा स्रोत हैं। कुछ का तर्क है कि दुर्लभ मामलों को मैन्युअल रूप से संभाला जाना चाहिए; अन्य कहते हैं कि बड़े पैमाने पर 1% भी लाखों लोगों को प्रभावित करता है और उसे इंजीनियर करना ही होगा।
डिज़ाइन, दस्तावेज़ीकरण और कोड लिखने से पहले सोचना
- कई लोग इस बात पर जोर देते हैं कि समस्या और प्रस्तावित समाधान को लिखकर व्यक्त कर पाना वास्तविक समझ का संकेत है।
- छोटे डिज़ाइन डॉक और डायग्राम को नौकरशाही नहीं, बल्कि सोचने के उपकरण के रूप में देखा जाता है।
- कुछ लोग कागज़ पर डिज़ाइन करने में संघर्ष करते हैं, उनका कहना है कि वे सिस्टम को केवल टाइप करते और पुनरावृत्ति करते हुए समझते हैं; दूसरे कहते हैं कि यह एक प्रशिक्षित की जा सकने वाली क्षमता है।
- टेस्ट-ड्रिवन डेवलपमेंट को “पहले डिज़ाइन” का आधुनिक समानांतर सुझाया जाता है।
डोमेन विशेषज्ञता और इंजीनियरिंग मानसिकता
- Multics की उपलब्धि संभव होने का एक प्रमुख कारण: प्रोग्रामर स्वयं एक गहरे डोमेन विशेषज्ञ भी थे।
- कई लोग तर्क देते हैं कि असली मूल्य समस्या-डोमेन को समझने और आवश्यकताओं को आकार देने में है, न कि केवल स्पेसिफिकेशन्स को कोड में बदलने में।
- चिंता यह है कि कई आधुनिक डेवलपर्स के पास पूर्ण-स्टैक समझ नहीं है और वे प्रदर्शन तथा मजबूती को बाद की बात मानते हैं।
कार्य वातावरण, पैमाना और भावनात्मक प्रतिक्रियाएँ
- पुराने वातावरण: शांत निजी कार्यालय, बड़े डेस्क, कोई नोटिफिकेशन नहीं, तकनीकी रूप से सक्षम प्रबंधन।
- आज: व्यवधान, मीटिंग्स, टूल्स की भरमार, और लगातार बढ़ती परस्पर जुड़ी प्रणालियाँ तथा बाहरी APIs।
- कुछ लोग प्रेरित और नॉस्टैल्जिक महसूस करते हैं; अन्य संशय में हैं, यह देखते हुए कि आधुनिक जटिलता और उलझी हुई integrations “एक ही पास” में पूर्णता को अवास्तविक बनाती हैं।
- एक बार-बार लौटने वाली भावना: कई डेवलपर्स खुद को कम उपयोग में महसूस करते हैं, और foundational systems के बजाय कम-प्रभाव वाले CRUD/ad work करते हुए निराशा और cynicism महसूस करते हैं।