डिज़ाइन और अनुसंधान

जनवरी 2003

(यह लेख NEPLS की गिरावट 2002 की बैठक में एक मुख्य भाषण से लिया गया है।)

इस देश के आगंतुक अक्सर आश्चर्यचकित होते हैं कि अमेरिकियों को बातचीत शुरू करने के लिए "आप क्या करते हैं?" पूछना पसंद है। मुझे यह सवाल कभी पसंद नहीं आया। मेरे पास इसका कोई साफ-सुथरा जवाब नहीं होता। लेकिन मुझे लगता है कि मैंने अंततः इस समस्या का समाधान कर लिया है। अब, जब कोई मुझसे पूछता है कि मैं क्या करता हूँ, तो मैं उनकी आँखों में सीधे देखता हूँ और कहता हूँ "मैं एक Lisp की नई बोली डिज़ाइन कर रहा हूँ।" मैं इस जवाब की सिफारिश करता हूँ उन सभी के लिए जिन्हें यह पसंद नहीं है कि उनसे पूछा जाए कि वे क्या करते हैं। बातचीत तुरंत अन्य विषयों की ओर मुड़ जाएगी।

मैं खुद को प्रोग्रामिंग भाषाओं पर अनुसंधान करने वाला नहीं मानता। मैं बस एक डिज़ाइन कर रहा हूँ, उसी तरह जैसे कोई एक इमारत या कुर्सी या एक नई टाइपफेस डिज़ाइन कर सकता है। मैं कुछ नया खोजने की कोशिश नहीं कर रहा हूँ। मैं बस एक ऐसी भाषा बनाना चाहता हूँ जो प्रोग्रामिंग के लिए अच्छी हो। कुछ मायनों में, यह धारणा जीवन को बहुत आसान बनाती है।

डिज़ाइन और अनुसंधान के बीच का अंतर नए बनाम अच्छे का सवाल लगता है। डिज़ाइन को नया होना जरूरी नहीं है, लेकिन इसे अच्छा होना चाहिए। अनुसंधान को अच्छा होना जरूरी नहीं है, लेकिन इसे नया होना चाहिए। मुझे लगता है कि ये दोनों रास्ते शीर्ष पर मिलते हैं: सबसे अच्छा डिज़ाइन अपने पूर्ववर्तियों को नए विचारों का उपयोग करके पार करता है, और सबसे अच्छा अनुसंधान समस्याओं को हल करता है जो न केवल नई होती हैं, बल्कि वास्तव में हल करने के लायक होती हैं। इसलिए अंततः हम एक ही गंतव्य की ओर बढ़ रहे हैं, बस इसे अलग-अलग दिशाओं से नज़दीक कर रहे हैं।

आज मैं जिस बारे में बात करने जा रहा हूँ वह यह है कि आपका लक्ष्य पीछे से कैसा दिखता है। जब आप प्रोग्रामिंग भाषाओं को एक डिज़ाइन समस्या के रूप में मानते हैं, तो आप क्या अलग करते हैं?

सबसे बड़ा अंतर यह है कि आप उपयोगकर्ता पर अधिक ध्यान केंद्रित करते हैं। डिज़ाइन इस सवाल से शुरू होता है, "यह किसके लिए है और उन्हें इसकी क्या आवश्यकता है?" एक अच्छा आर्किटेक्ट, उदाहरण के लिए, एक डिज़ाइन बनाने से शुरू नहीं करता है जिसे वह फिर उपयोगकर्ताओं पर थोपता है, बल्कि वह लक्षित उपयोगकर्ताओं का अध्ययन करता है और यह पता लगाता है कि उन्हें क्या चाहिए।

ध्यान दें कि मैंने "उन्हें क्या चाहिए" कहा, "उन्हें क्या चाहिए" नहीं। मेरा मतलब यह नहीं है कि डिज़ाइनर के रूप में काम करना एक प्रकार के शॉर्ट-ऑर्डर कुक के रूप में काम करना है, जो ग्राहक आपको जो बताता है उसे बनाता है। यह कला के क्षेत्र में क्षेत्र से क्षेत्र में भिन्न होता है, लेकिन मुझे नहीं लगता कि कोई ऐसा क्षेत्र है जिसमें सबसे अच्छा काम उन लोगों द्वारा किया जाता है जो बस वही बनाते हैं जो ग्राहक उन्हें बताते हैं।

ग्राहक हमेशा सही होता है इस अर्थ में कि अच्छे डिज़ाइन का माप यह है कि यह उपयोगकर्ता के लिए कितना अच्छा काम करता है। यदि आप एक उपन्यास बनाते हैं जो सभी को बोर करता है, या एक कुर्सी जो बैठने में भयानक असुविधाजनक है, तो आपने एक बुरा काम किया है, बस। यह कहना कोई बचाव नहीं है कि उपन्यास या कुर्सी को सबसे उन्नत सैद्धांतिक सिद्धांतों के अनुसार डिज़ाइन किया गया है।

और फिर भी, उपयोगकर्ता के लिए जो काम करता है उसे बनाना केवल वही नहीं है जो उपयोगकर्ता आपको बताता है। उपयोगकर्ताओं को यह नहीं पता होता कि सभी विकल्प क्या हैं, और वे अक्सर यह समझने में गलत होते हैं कि वे वास्तव में क्या चाहते हैं।

मुझे लगता है कि इस विरोधाभास का उत्तर यह है कि आपको उपयोगकर्ता के लिए डिज़ाइन करना है, लेकिन आपको वह डिज़ाइन करना है जो उपयोगकर्ता को चाहिए, न कि केवल वही जो वह कहता है कि वह चाहता है। यह डॉक्टर होने के समान है। आप केवल एक रोगी के लक्षणों का इलाज नहीं कर सकते। जब एक रोगी आपको अपने लक्षण बताता है, तो आपको यह पता लगाना होता है कि वास्तव में उसके साथ क्या गलत है, और उसका इलाज करना होता है।

उपयोगकर्ता पर यह ध्यान केंद्रित करना एक प्रकार का अक्सिओम है जिससे अच्छे डिज़ाइन का अधिकांश अभ्यास निकाला जा सकता है, और जिसके चारों ओर अधिकांश डिज़ाइन मुद्दे केंद्रित होते हैं।

यदि अच्छे डिज़ाइन को उपयोगकर्ता की आवश्यकता को पूरा करना है, तो उपयोगकर्ता कौन है? जब मैं कहता हूँ कि डिज़ाइन को उपयोगकर्ताओं के लिए होना चाहिए, तो मेरा मतलब यह नहीं है कि अच्छे डिज़ाइन का लक्ष्य किसी प्रकार के सबसे कम सामान्य भाजक पर होना चाहिए। आप किसी भी उपयोगकर्ता समूह को चुन सकते हैं जो आप चाहते हैं। यदि आप एक उपकरण डिज़ाइन कर रहे हैं, उदाहरण के लिए, तो आप इसे शुरुआती से लेकर विशेषज्ञों तक किसी के लिए भी डिज़ाइन कर सकते हैं, और जो एक समूह के लिए अच्छा डिज़ाइन है वह दूसरे के लिए बुरा हो सकता है। बिंदु यह है कि, आपको कुछ उपयोगकर्ता समूह चुनना होगा। मुझे नहीं लगता कि आप अच्छे या बुरे डिज़ाइन के बारे में बात कर सकते हैं जब तक कि किसी लक्षित उपयोगकर्ता का संदर्भ न हो।

आपको अच्छे डिज़ाइन की संभावना अधिक होती है यदि लक्षित उपयोगकर्ताओं में डिज़ाइनर स्वयं शामिल होता है। जब आप किसी ऐसे समूह के लिए कुछ डिज़ाइन करते हैं जिसमें आप शामिल नहीं होते हैं, तो यह उन लोगों के लिए होता है जिन्हें आप अपने से कम परिष्कृत मानते हैं, न कि अधिक परिष्कृत।

यह एक समस्या है, क्योंकि उपयोगकर्ता को नीचा दिखाना, चाहे कितनी भी भलाई से हो, डिज़ाइनर को भ्रष्ट करने के लिए अनिवार्य रूप से प्रतीत होता है। मुझे संदेह है कि अमेरिका में बहुत कम आवास परियोजनाएँ उन आर्किटेक्ट्स द्वारा डिज़ाइन की गई थीं जो उनमें रहने की उम्मीद करते थे। आप प्रोग्रामिंग भाषाओं में भी यही देख सकते हैं। C, Lisp, और Smalltalk अपने स्वयं के डिज़ाइनरों के उपयोग के लिए बनाए गए थे। Cobol, Ada, और Java, अन्य लोगों के उपयोग के लिए बनाए गए थे।

यदि आप सोचते हैं कि आप कुछ बेवकूफों के लिए डिज़ाइन कर रहे हैं, तो संभावना है कि आप कुछ अच्छा डिज़ाइन नहीं कर रहे हैं, यहां तक कि बेवकूफों के लिए भी।

हालांकि, यदि आप सबसे परिष्कृत उपयोगकर्ताओं के लिए कुछ डिज़ाइन कर रहे हैं, तो भी आप मानवों के लिए डिज़ाइन कर रहे हैं। अनुसंधान में यह अलग है। गणित में आप अमूर्तताओं को इस आधार पर नहीं चुनते कि वे मानवों के लिए समझने में आसान हैं; आप जो भी प्रमाण को छोटा बनाता है उसे चुनते हैं। मुझे लगता है कि यह सामान्य रूप से विज्ञान के लिए सच है। वैज्ञानिक विचार मानवों के लिए एर्गोनोमिक नहीं होते हैं।

कला में, चीजें बहुत अलग होती हैं। डिज़ाइन पूरी तरह से लोगों के बारे में है। मानव शरीर एक अजीब चीज है, लेकिन जब आप एक कुर्सी डिज़ाइन कर रहे होते हैं, तो आप उसी के लिए डिज़ाइन कर रहे होते हैं, और इससे बचने का कोई तरीका नहीं है। सभी कलाएँ मानवों के हितों और सीमाओं को ध्यान में रखकर काम करती हैं। उदाहरण के लिए, चित्रकला में, सभी अन्य चीजें समान होने पर, एक चित्र जिसमें लोग होते हैं, बिना लोगों के चित्र की तुलना में अधिक दिलचस्प होगा। यह केवल इतिहास का एक संयोग नहीं है कि पुनर्जागरण की महान चित्रकला सभी लोगों से भरी हुई है। यदि वे नहीं होते, तो चित्रकला के रूप में एक माध्यम को वह प्रतिष्ठा नहीं मिलती जो इसे मिलती है।

चाहे आपको पसंद हो या न हो, प्रोग्रामिंग भाषाएँ भी लोगों के लिए होती हैं, और मुझे संदेह है कि मानव मस्तिष्क भी मानव शरीर की तरह ही लंपट और अद्वितीय है। कुछ विचार लोगों के लिए समझने में आसान होते हैं और कुछ नहीं होते। उदाहरण के लिए, हमें विवरणों के साथ निपटने की बहुत सीमित क्षमता प्रतीत होती है। यही तथ्य प्रोग्रामिंग भाषाओं को पहले स्थान पर एक अच्छा विचार बनाता है; यदि हम विवरण को संभाल सकते, तो हम बस मशीन भाषा में प्रोग्राम कर सकते थे।

याद रखें, भाषाएँ मुख्य रूप से तैयार कार्यक्रमों के लिए एक रूप नहीं हैं, बल्कि कुछ ऐसा हैं जिसमें कार्यक्रम विकसित किए जाने हैं। कला के किसी भी क्षेत्र में कोई भी आपको बता सकता है कि आप दोनों स्थितियों के लिए विभिन्न माध्यमों की आवश्यकता हो सकती है। उदाहरण के लिए, संगमरमर एक अच्छा, टिकाऊ माध्यम है तैयार विचारों के लिए, लेकिन नए विचारों को विकसित करने के लिए एक निराशाजनक रूप से कठोर है।

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

हम अक्सर ऐसा व्यवहार करते हैं जैसे कि एक भाषा का परीक्षण यह है कि तैयार कार्यक्रम उसमें कितने अच्छे दिखते हैं। जब आप दो भाषाओं में एक ही कार्यक्रम देखते हैं, और एक संस्करण बहुत छोटा होता है, तो यह बहुत विश्वसनीय लगता है। जब आप समस्या को कला की दिशा से देखते हैं, तो आप इस प्रकार के परीक्षण पर निर्भर होने की संभावना कम होती है। आप एक प्रोग्रामिंग भाषा नहीं चाहते जो संगमरमर की तरह हो।

उदाहरण के लिए, सॉफ़्टवेयर विकसित करने में एक इंटरैक्टिव टॉपलेवल होना एक बड़ा लाभ है, जिसे Lisp में पढ़-आकलन-प्रिंट लूप कहा जाता है। और जब आपके पास एक होता है, तो इसका भाषा के डिज़ाइन पर वास्तविक प्रभाव पड़ता है। उदाहरण के लिए, यह एक भाषा के लिए अच्छा काम नहीं करेगा जहाँ आपको उनका उपयोग करने से पहले वेरिएबल्स की घोषणा करनी होती है। जब आप बस टॉपलेवल में अभिव्यक्तियाँ टाइप कर रहे होते हैं, तो आप चाहते हैं कि आप x को किसी मान पर सेट कर सकें और फिर x पर कुछ करना शुरू कर सकें। आप पहले x के प्रकार की घोषणा नहीं करना चाहते। आप किसी भी पूर्वधारणा पर विवाद कर सकते हैं, लेकिन यदि एक भाषा को सुविधाजनक होने के लिए एक टॉपलेवल की आवश्यकता है, और अनिवार्य प्रकार की घोषणाएँ एक टॉपलेवल के साथ असंगत हैं, तो कोई भी भाषा जो प्रकार की घोषणाओं को अनिवार्य बनाती है, उसमें प्रोग्राम करना सुविधाजनक नहीं हो सकता।

व्यवहार में, अच्छे डिज़ाइन के लिए आपको अपने उपयोगकर्ताओं के करीब रहना और निकट रहना होगा। आपको अपने विचारों को वास्तविक उपयोगकर्ताओं पर लगातार कैलिब्रेट करना होगा, विशेष रूप से शुरुआत में। जेन ऑस्टेन के उपन्यासों के अच्छे होने के कारणों में से एक यह है कि उसने उन्हें अपने परिवार के सामने जोर से पढ़ा। यही कारण है कि वह कभी भी आत्म-प्रवृत्त कलात्मक परिदृश्यों में नहीं डूबती, या दिखावटी दार्शनिकता में नहीं जाती। (दार्शनिकता वहाँ है, लेकिन यह कहानी में बुनी गई है न कि इसे एक लेबल की तरह चिपकाया गया है।) यदि आप एक औसत "साहित्यिक" उपन्यास को खोलते हैं और कल्पना करते हैं कि आप इसे अपने दोस्तों के सामने पढ़ रहे हैं जैसे कि आपने इसे लिखा है, तो आप बहुत अच्छी तरह से महसूस करेंगे कि इस प्रकार की चीज़ पाठक पर कितना बोझ है।

सॉफ़्टवेयर की दुनिया में, इस विचार को "बुरा बेहतर है" के रूप में जाना जाता है। वास्तव में, "बुरा बेहतर है" के विचार में कई विचार मिश्रित होते हैं, यही कारण है कि लोग अभी भी इस बारे में बहस कर रहे हैं कि क्या बुरा वास्तव में बेहतर है या नहीं। लेकिन उस मिश्रण में एक मुख्य विचार यह है कि यदि आप कुछ नया बना रहे हैं, तो आपको जितनी जल्दी हो सके उपयोगकर्ताओं के सामने एक प्रोटोटाइप लाना चाहिए।

वैकल्पिक दृष्टिकोण को "हेल मैरी रणनीति" कहा जा सकता है। इसके बजाय कि आप जल्दी से एक प्रोटोटाइप निकालें और धीरे-धीरे इसे परिष्कृत करें, आप एक लंबे टचडाउन पास में पूरा, तैयार उत्पाद बनाने की कोशिश करते हैं। जितना मुझे पता है, यह आपदा के लिए एक नुस्खा है। अनगिनत स्टार्टअप्स ने इस तरह से इंटरनेट बबल के दौरान खुद को नष्ट कर दिया। मैंने कभी भी ऐसा मामला नहीं सुना जहाँ यह काम किया हो।

जो लोग सॉफ़्टवेयर की दुनिया के बाहर हैं, वे शायद यह नहीं समझते कि "बुरा बेहतर है" कला में भी पाया जाता है। उदाहरण के लिए, चित्रण में, यह विचार पुनर्जागरण के दौरान खोजा गया था। अब लगभग हर चित्रण शिक्षक आपको बताएगा कि एक सटीक चित्र प्राप्त करने का सही तरीका यह नहीं है कि आप किसी वस्तु के आकार के चारों ओर धीरे-धीरे काम करें, क्योंकि गलतियाँ जमा होंगी और आप अंत में पाएंगे कि रेखाएँ मिलती नहीं हैं। इसके बजाय, आपको कुछ तेज़ रेखाएँ लगभग सही जगह पर खींचनी चाहिए, और फिर इस प्रारंभिक स्केच को धीरे-धीरे परिष्कृत करना चाहिए।

अधिकांश क्षेत्रों में, प्रोटोटाइप पारंपरिक रूप से विभिन्न सामग्रियों से बनाए गए हैं। धातु में काटे जाने वाले टाइपफेस को शुरू में कागज पर ब्रश से डिज़ाइन किया गया था। कांस्य में ढाले जाने वाले मूर्तियों को मोम में मॉडल किया गया था। टेपेस्ट्री पर कढ़ाई करने के लिए पैटर्न कागज पर स्याही धोने से बनाए गए थे। पत्थर से निर्मित भवनों का परीक्षण छोटे पैमाने पर लकड़ी में किया गया था।

जब पंद्रहवीं शताब्दी में तेल पेंट लोकप्रिय हुआ, तो यह इतना रोमांचक था क्योंकि आप वास्तव में प्रोटोटाइप से तैयार काम बना सकते थे। यदि आप चाहें तो आप एक प्रारंभिक चित्र बना सकते थे, लेकिन आप इसके लिए बाध्य नहीं थे; आप सभी विवरणों को काम कर सकते थे, और यहां तक कि जब आप चित्र बना रहे होते हैं, तो प्रमुख परिवर्तन भी कर सकते थे।

आप सॉफ़्टवेयर में भी ऐसा कर सकते हैं। एक प्रोटोटाइप केवल एक मॉडल नहीं होना चाहिए; आप इसे तैयार उत्पाद में परिष्कृत कर सकते हैं। मुझे लगता है कि आपको हमेशा ऐसा करना चाहिए जब आप कर सकें। यह आपको रास्ते में नए अंतर्दृष्टियों का लाभ उठाने की अनुमति देता है। लेकिन शायद इससे भी अधिक महत्वपूर्ण, यह मनोबल के लिए अच्छा है।

मनोबल डिज़ाइन में कुंजी है। मुझे आश्चर्य है कि लोग इसके बारे में अधिक बात क्यों नहीं करते। मेरे पहले चित्रण शिक्षकों में से एक ने मुझसे कहा: यदि आप कुछ चित्रित करते समय बोर हो रहे हैं, तो चित्र बोरिंग लगेगा। उदाहरण के लिए, मान लीजिए कि आपको एक इमारत चित्रित करनी है, और आप प्रत्येक ईंट को व्यक्तिगत रूप से चित्रित करने का निर्णय लेते हैं। आप ऐसा कर सकते हैं यदि आप चाहें, लेकिन यदि आप आधे रास्ते में बोर हो जाते हैं और प्रत्येक को देखने के बजाय यांत्रिक रूप से ईंटें बनाने लगते हैं, तो चित्र उस स्थिति से बदतर लगेगा यदि आपने केवल ईंटों का सुझाव दिया होता।

एक प्रोटोटाइप को धीरे-धीरे परिष्कृत करके कुछ बनाना मनोबल के लिए अच्छा होता है क्योंकि यह आपको संलग्न रखता है। सॉफ़्टवेयर में, मेरा नियम है: हमेशा कार्यशील कोड रखें। यदि आप कुछ लिख रहे हैं जिसे आप एक घंटे में परीक्षण कर सकेंगे, तो आपके पास आपको प्रेरित करने के लिए तत्काल पुरस्कार की संभावना होती है। कला में भी यही सच है, और विशेष रूप से तेल चित्रकला में। अधिकांश चित्रकार एक धुंधले स्केच से शुरू करते हैं और धीरे-धीरे इसे परिष्कृत करते हैं। यदि आप इस तरह काम करते हैं, तो सिद्धांत में, आपको कभी भी ऐसा कुछ समाप्त नहीं करना चाहिए जो वास्तव में अधूरा दिखता हो। वास्तव में, चित्रकारों के बीच एक कहावत भी है: "एक चित्र कभी समाप्त नहीं होता, आप बस उस पर काम करना बंद कर देते हैं।" यह विचार किसी भी व्यक्ति के लिए परिचित होगा जिसने सॉफ़्टवेयर पर काम किया है।

मनोबल एक और कारण है कि किसी असंवेदनशील उपयोगकर्ता के लिए कुछ डिज़ाइन करना कठिन है। किसी ऐसी चीज़ में रुचि बनाए रखना कठिन है जो आपको खुद पसंद नहीं है। कुछ अच्छा बनाने के लिए, आपको यह सोचना होगा, "वाह, यह वास्तव में महान है," न कि "क्या बकवास है; वे बेवकूफ इसे पसंद करेंगे।"

डिज़ाइन का मतलब है मानवों के लिए चीजें बनाना। लेकिन केवल उपयोगकर्ता ही मानव नहीं है। डिज़ाइनर भी मानव है।

ध्यान दें कि इस समय मैं "डिज़ाइनर" के बारे में बात कर रहा हूँ। डिज़ाइन को आमतौर पर किसी एक व्यक्ति के नियंत्रण में होना चाहिए ताकि यह अच्छा हो सके। और फिर भी, ऐसा प्रतीत होता है कि कई लोग एक अनुसंधान परियोजना पर सहयोग कर सकते हैं। मुझे लगता है कि यह अनुसंधान और डिज़ाइन के बीच का सबसे दिलचस्प अंतर है।

कला में सहयोग के प्रसिद्ध उदाहरण रहे हैं, लेकिन उनमें से अधिकांश आणविक बंधन के मामलों की तरह प्रतीत होते हैं न कि परमाणु संलयन के। एक ओपेरा में यह सामान्य है कि एक व्यक्ति लिब्रेट्टो लिखता है और दूसरा संगीत लिखता है। और पुनर्जागरण के दौरान, उत्तरी यूरोप के कारीगरों को अक्सर इतालवी चित्रों के पृष्ठभूमि में परिदृश्य बनाने के लिए नियुक्त किया जाता था। लेकिन ये सच्चे सहयोग नहीं हैं। ये रॉबर्ट फ्रॉस्ट के "अच्छी बाड़ें अच्छे पड़ोसी बनाती हैं" के उदाहरणों की तरह हैं। आप अच्छे डिज़ाइन के उदाहरणों को एक साथ रख सकते हैं, लेकिन प्रत्येक व्यक्तिगत परियोजना के भीतर, एक व्यक्ति को नियंत्रण में होना चाहिए।

मैं यह नहीं कह रहा कि अच्छे डिज़ाइन के लिए एक व्यक्ति को सब कुछ सोचना आवश्यक है। किसी ऐसे व्यक्ति की सलाह जो आपके निर्णय पर भरोसा करता है, उससे अधिक मूल्यवान कुछ नहीं है। लेकिन बात करने के बाद, यह तय करना कि क्या करना है, एक व्यक्ति के पास होना चाहिए।

यह क्यों है कि अनुसंधान सहयोगियों द्वारा किया जा सकता है और डिज़ाइन नहीं किया जा सकता? यह एक दिलचस्प सवाल है। मुझे इसका उत्तर नहीं पता। शायद, यदि डिज़ाइन और अनुसंधान एकत्र होते हैं, तो सबसे अच्छा अनुसंधान भी अच्छा डिज़ाइन होता है, और वास्तव में इसे सहयोगियों द्वारा नहीं किया जा सकता। कई सबसे प्रसिद्ध वैज्ञानिक अकेले काम करते प्रतीत होते हैं। लेकिन मैं यह कहने के लिए पर्याप्त नहीं जानता कि क्या यहाँ एक पैटर्न है। यह हो सकता है कि कई प्रसिद्ध वैज्ञानिक उस समय काम करते थे जब सहयोग कम सामान्य था।

जो भी कहानी विज्ञान में है, कला में सच्चा सहयोग अत्यंत दुर्लभ प्रतीत होता है। समिति द्वारा डिज़ाइन करना बुरे डिज़ाइन का पर्याय है। ऐसा क्यों है? क्या इस सीमा को पार करने का कोई तरीका है?

मुझे लगता है कि ऐसा नहीं है-- कि अच्छे डिज़ाइन के लिए एक तानाशाह की आवश्यकता होती है। एक कारण यह है कि अच्छे डिज़ाइन को एक ही टुकड़े में होना चाहिए। डिज़ाइन केवल मानवों के लिए नहीं है, बल्कि व्यक्तिगत मानवों के लिए है। यदि एक डिज़ाइन एक विचार का प्रतिनिधित्व करता है जो एक व्यक्ति के सिर में फिट होता है, तो विचार उपयोगकर्ता के सिर में भी फिट होगा।