क्या पिछले 20 वर्षों में वास्तव में एक बात नहीं हुई है, जिसने भारी सॉफ्टवेयर विकास लाभ प्रदान किया है? [बन्द है]

45

में कोई जादुई शब्द , फ्रेड ब्रूक्स सॉफ्टवेयर इंजीनियरिंग, सबसे अच्छा द्वारा अभिव्यक्त के भविष्य के बारे में भविष्यवाणी की एक किस्म में आता है:

प्रौद्योगिकी या प्रबंधन तकनीक में, कोई एकल विकास नहीं है, जो कि उत्पादकता में, विश्वसनीयता में, सादगी में, यहां तक कि उत्पादकता में सुधार के एक क्रम का वादा करता है ।

उनकी दलील बहुत ठोस है। ब्रूक्स 1986 में लिख रहा था: क्या वह सही था? क्या 2014 में डेवलपर्स 1986 में अपने समकक्षों की तुलना में 10x से कम दर पर सॉफ़्टवेयर का उत्पादन करते हैं? कुछ उपयुक्त मीट्रिक द्वारा - उत्पादकता में वास्तव में कितना बड़ा लाभ हुआ है?

productivity

— पैट्रिक कॉलिन्स
स्रोत

4

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— वर्ल्ड इंजीनियर

58

क्या 2014 में डेवलपर्स 1986 में अपने समकक्षों की तुलना में 10x से कम दर पर सॉफ़्टवेयर का उत्पादन करते हैं?

मुझे लगता है कि तब से उत्पादकता में कम से कम सुधार का क्रम है। लेकिन एक भी विकास का लाभ उठाकर, प्रौद्योगिकी या प्रबंधन तकनीक में नहीं।

उत्पादकता में वृद्धि कारकों के संयोजन के बारे में आई है। नोट: यह एक व्यापक सूची नहीं है:

बेहतर संकलक
अत्यधिक शक्तिशाली कंप्यूटर
IntelliSense
वस्तु अभिविन्यास
कार्यात्मक अभिविन्यास
बेहतर मेमोरी मैनेजमेंट तकनीक
सीमा की जाँच
स्थैतिक कोड विश्लेषण
मजबूत टाइपिंग
इकाई का परीक्षण
बेहतर प्रोग्रामिंग भाषा डिजाइन
कोड पीढ़ी
स्रोत कोड नियंत्रण प्रणाली
कोड का पुन: उपयोग

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

ध्यान दें कि इनमें से कुछ तकनीकें साठ के दशक के बाद से मौजूद हैं, लेकिन हाल ही में व्यापक मान्यता और गोद लेने का पालन किया गया है।

— रॉबर्ट हार्वे
स्रोत

15

बेहतर स्रोत / संस्करण नियंत्रण प्रणाली मत भूलना।

— डोभाल

7

ठीक है। मुझे लगता है कि हम इस सूची में एक और दर्जन (या सौ) चीजें जोड़ सकते हैं।

— रॉबर्ट हार्वे

44

@ user61852: क्योंकि उम्मीदें हमेशा वास्तविकता से अधिक होती हैं।

— रॉबर्ट हार्वे

9

@ user61852 thecodelesscode.com/case/154

— Idan Arye

1

@RossPatterson: हमने मूल रूप से इस बिंदु पर डेवलपर टूल के लिए जो आवश्यक है, प्राप्त किया है। हम इन दिनों अपने संकलन सीपीयू चक्रों के साथ मूर्खतापूर्ण व्यर्थ बातें भी कर रहे हैं क्योंकि हम कर सकते हैं --- टेम्पलेट मेटाप्रोग्रामिंग को देखो। याद रखें कि हम 80 के दशक की तुलना कर रहे हैं; जब मैं निश्चित रूप से एक डेवलपर नहीं था, तब मैंने 1990 में निर्मित मशीन पर कोड करना सीख लिया था।

— tmyklebu

71

रॉबर्ट हार्वे का उत्तर अच्छा है, लेकिन मुझे लगता है कि उन्होंने छोड़ दिया कि सबसे बड़ा कारण क्या हो सकता है, क्योंकि प्रोग्रामर पहले से कहीं अधिक उत्पादक हैं: सॉफ्टवेयर पुस्तकालयों की व्यापक उपलब्धता।

जब मैंने अपना करियर शुरू किया, तो कोई भी STL, .NET, QT, इत्यादि नहीं था। आपके पास कच्चा C या C ++ था, और यह इसके बारे में था।

वे चीजें जो दिन या सप्ताह या काम (XML पार्सिंग, टीसीपी / आईपी कनेक्शन, एचटीटीपी कम्यूनिटी) लेती थीं, अब सी # कोड की एक मुट्ठी भर लाइनों के साथ किया जा सकता है। यह वह जगह है जहां हमने समग्र डेवलपर उत्पादकता के मामले में बेहतर परिमाण के आदेश दिए हैं।

हमारा वर्तमान उत्पाद एक डॉकिंग विंडो फ्रेमवर्क का उपयोग करता है जिसे हमने एक विक्रेता से खरीदा था। यह मुझे कुछ ही मिनटों में पूरी तरह कार्यात्मक डॉकिंग विंडो UI है। मुझे लगता है कि win32 एपीआई का उपयोग करने के दिनों में ऐसा करने के लिए ले जाएगा कि सोचने के लिए कंपकंपी।

— 17 का 26
स्रोत

19

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

— NWard

15

@ अब तक मूल रूप से अतिप्रवाह =)

— क्रिस

2

@tmyklebu people just found other (generally better) solutions[प्रशस्ति पत्र की जरूरत]। एक्सएमएल के "पहाड़ों" को जल्दी से पार्स करने के लिए पुस्तकालयों का उपयोग करना कई तरह से अद्वितीय समाधानों को कोडित करने से बेहतर है। एक्सएमएल निश्चित रूप से अत्यधिक चंचल और दोहरावदार हो सकता है, लेकिन पुस्तकालय इसे ज्यादातर स्थितियों में एक हवा का उपयोग करते हैं।

— वर्नरसीडी

5

@tmyklebu के रूप में दर्दनाक के रूप में यह बड़ी मात्रा में XML पार्स करने के लिए हो सकता है, एक undocumented स्वामित्व प्रारूप में बाइनरी डेटा की बड़ी मात्रा को पार्स करने की कोशिश करें, जैसा कि अधिकांश अनुप्रयोगों द्वारा लिखा गया है, जो लगभग 1986 में लिखा गया था।

— James_pile

2

@tmyklebu किसी को भी दिन में (या यहां तक कि मेगाबाइट!) किसी भी चीज़ के गीगाबाइट की आवश्यकता नहीं थी। XML की वह राशि क्या उत्पन्न करती है, यह तथ्य है कि हम स्टोर कर रहे हैं और पहले से कहीं अधिक डेटा ट्रैक कर रहे हैं। james_pic सही है, XML एक तरह से bazillion मालिकाना बाइनरी स्वरूपों को किक करने से बेहतर है। XML वर्डी हो सकता है, लेकिन यह क्रॉस-प्लेटफॉर्म, मानव पठनीय और अत्यधिक लचीला है। वे सभी मूल्यवान लक्षण हैं।

— 17 का 26

62

तर्क के लिए, मैं फ्रेड ब्रूक्स के दावे से असहमत हूं ।

प्रौद्योगिकी में एक सुधार है जिसने अकेले उत्पादकता में सुधार के क्रम में सुधार की अनुमति दी है: इंटरनेट , और पिछले दो दशकों में हर घर में इंटरनेट कनेक्शन की प्रगतिशील उपलब्धता।

एक डेवलपर के रूप में लगभग हर समस्या का तुरंत जवाब पाने में सक्षम होने के नाते उत्पादकता में भारी वृद्धि को सक्षम बनाता है। पता नहीं कैसे JQuery में nth तत्व का चयन करें? Google खोज स्टैक ओवरफ्लो पर सटीक प्रश्न का उत्तर देती है । पता नहीं कैसे overflowसीएसएस में उपयोग करने के लिए ? मोज़िला का MDN यहाँ है । भूल गए कि virtualC # में कीवर्ड का क्या मतलब है? Google फिर से मदद करता है ।

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

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

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

ज्यादातर मुद्दों पर एक जवाब की तत्काल उपलब्धता का महत्व विशेष रूप से ध्यान देने योग्य है यदि हम ध्यान में रखते हैं कि किसी परियोजना पर एक टीम द्वारा खर्च किए गए अधिकांश समय इसे बनाए रखने में बिताया जाता है।

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

क्या यह उत्पादकता में x10 वृद्धि को सही ठहराएगा? बताना मुश्किल है।

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

— आर्सेनी मूरज़ेंको
स्रोत

4

"इंटरनेट" एक भी विकास नहीं है।

— बेन वोइगट

1

@BenVoigt: मैं इसे ब्रूक्स के उद्धरण से एक तकनीक के रूप में अर्हता प्राप्त करूँगा । लेकिन मैं मानता हूं, शर्तें स्पष्ट नहीं हो सकती हैं: पहला, क्या यह इंटरनेट (1980 के दशक की शुरुआत) या वर्ल्ड वाइड वेब (1989) होगा? दूसरा, यह केवल तकनीक ही नहीं है जो आवश्यक थी, लेकिन इसकी लोकप्रियता थी।

— आर्सेनी मूरज़ेंको

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

— बेन वोइगट

5

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

— user1172763

जटिलता शत्रु है। आप अपने सिर में जेसीएल पकड़ सकते हैं और हाथ में मैनुअल पकड़ सकते हैं; एक एकल शेल्फ पूरे सिस्टम को दस्तावेज़ित कर सकता है। अब प्रणालियों के आकार और उनके परिवर्तन की अंतर्निहित दर में बहुत बड़ा विस्फोट हुआ है।

— pjc50

13

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

— AlexFoxGill
स्रोत

चांदी की गोली को इंगित करने वाले आप एकमात्र व्यक्ति हैं। न केवल इसने प्रोग्रामर्स को एक परिमाण द्वारा अधिक उत्पादक बनाया है, बल्कि वास्तव में आदेश के कई परिमाण द्वारा।

— डंक

+1000 - अस्पष्ट मुद्दे पर कुछ दिनों के लिए काम करने के बजाय आप कुछ मिनटों में मदद ले सकते हैं।

— 15:15 बजे jqa

7

मेरा सुझाव है कि रुझान हमें दूसरी दिशा में खींच रहे हैं (यानी कम उत्पादकता की ओर) कम से कम उतने ही मजबूत हैं जितना कि आपके बारे में पूछे गए रुझान। VB6 या PowerBuilder जैसे क्लाइंट / सर्वर डेवलपमेंट टूल करने का अनुभव "रैपिड एप्लिकेशन डेवलपमेंट" (RAD) आदर्श के बहुत करीब आया। आपको अपने फ़ॉर्म खींचने पड़े, और आपके प्रक्रियात्मक या SQL कोड के लिए स्पष्ट हुक थे।

वेब विकास, कम से कम शुरुआत में, बहुत सारी तकनीकों और बुनियादी ढांचे को नष्ट कर दिया जिसने इन चीजों को संभव बना दिया, और कई क्लाइंट / सर्वर डेवलपर्स को केवल डेवलपर्स के रूप में बंद कर दिया, या वीबी 6 के लिए सख्त रूप से बंद कर दिया।

भारी ग्राहक-चालित वेब विकास के लिए संक्रमण अभी तक एक और स्लैश-एंड-बर्न अनुभव था; Microsoft WebForms के साथ RAD आदर्श में वापस आ रहा था, और फिर यह जल्दी से पक्ष से बाहर हो गया। इसके बजाय डेवलपर्स को बुनियादी ढांचे का दुरुपयोग करने की उम्मीद की गई थी (उदाहरण के लिए XMLHttpRequest, जो शायद ही कभी XML के लिए उपयोग किया जाता है) और अन्यथा बंदर अपनी वेबसाइटों को अधिक इंटरैक्टिव बनाने के प्रयास में अमूर्त के निम्न स्तर पर हैं।

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

इसके विपरीत, अधिक समकालीन डेवलपर्स यह सोचते हैं कि हममें से जो क्लाइंट / सर्वर डेवलपमेंट (या यहां तक कि पोस्टबैक-आधारित वेब डेवलपमेंट) करते हैं, उनमें शॉर्टकट का सहारा लेने की प्रवृत्ति होती है (और इसका मतलब है कि बुरे तरीके से)। यह समझ में आता है, लेकिन मुझे अभी भी लगता है कि समकालीन विकास जिस तरह से किया गया है, वह आश्चर्यजनक रूप से निम्न स्तर का है, और "सिल्वर बुलेट" की खोज के दिनों ने लगता है कि हममें से उन लोगों का मजाक उड़ाने के युग को रास्ता दे दिया है जो खनन के ज्ञान पर सवाल उठाते हैं और हमारे अपने नेतृत्व को गलाने।

— user1172763
स्रोत

क्या आपने Meteor.js देखा है?

— स्ट्रगलर

2

@strugee हाँ, और मुझे लगता है कि Meteor.js सही दिशा में एक कदम हो सकता है। हालाँकि, तथ्य यह है कि हम अनिवार्य रूप से "तकनीकी रूप से कम से कम 3-4 बार" शुरू कर चुके हैं क्योंकि ब्रूक्स ने अपनी पुस्तक (पीसी के लिए संक्रमण का जिक्र करते हुए, फिर क्लाइंट / सर्वर पर, फिर वेब पर, और फिर लिखी है) AJAX) यकीनन हमें "सिल्वर बुलेट" खोजने या उत्पादकता में रैखिक सुधार करने से रोक दिया गया है। समय बताएगा कि वर्तमान विकास तकनीकें कब तक (और सुधार) सहती हैं। आशावाद के कुछ कारण हैं ... हर कोई अब एक मजबूत, क्रॉस-प्लेटफ़ॉर्म बिंदु तक पहुंच रहा है।

— user1172763

5

प्रौद्योगिकी बहुत उन्नत हो गई है और अब हमारे पास रॉबर्ट हार्वे के पास उनके उत्तर में सभी चीजें हैं, लेकिन:

समस्या बदलती आवश्यकताओं की लगती है । क्लाइंट को पता है कि सॉफ़्टवेयर प्रोजेक्ट की आवश्यकताओं को बदलते समय सामग्रियों की बर्बादी नहीं होगी, इसलिए वे ऐसा करते हैं। इस तरह की आवश्यकता में परिवर्तन लगभग कभी नहीं होता है जब एक भौतिक-विश्व परियोजना जैसे भवन, आधा हो जाता है।
एक अन्य महत्वपूर्ण पहलू यह है कि प्रोग्रामिंग अत्यधिक होना जारी है करतूत । शायद ही कभी, रेड-जनरेट कोड पहले हाथ से संशोधित किए बिना उत्पादन में चला जाता है।
कोड अत्यधिक जटिल बना हुआ है , और यह जटिलता नई तकनीकों के साथ घटती नहीं दिख रही है।
जो समय सीमाएं पूरी नहीं हुईं या बजट से अधिक नहीं हुईं , वे अन्य विषयों में अधिक से अधिक जारी रहती हैं, और अक्सर छिपी हुई लागतों को उत्पन्न करने के लिए तकनीकी ऋण उन्हें पूरा करने के लिए खर्च किया जाता है।
कुछ ऐसा है, जो बिना किसी संदेह के हुआ है, वह यह है कि कम्पार्टमेंटलाइज़ेशन का आधार है। प्रौद्योगिकियों के बारे में सरासर यह जानना जरूरी है कि प्रोग्रामर को बहुत कम तकनीकों को विशेष रूप से विकसित करना है ताकि वे वास्तव में अच्छे बन सकें, एक बड़ी परियोजना को पूरा करने के लिए विभिन्न प्रकार के विशेषज्ञों की आवश्यकता होती है।
एक बात जो सॉफ्टवेयर जटिलता के बारे में बात करती है, वह यह है कि दुनिया में सचमुच सैकड़ों कार निर्माता हैं, एक ऑपरेटिंग सिस्टम बनाने और मेनटेन करने में सक्षम कंपनियों की सूची , (डेस्कटॉप, मोबाइल, एम्बेडेड या अन्यथा), उंगलियों से गिना जा सकता है अपने हाथों से।
उपरोक्त सभी ने एक ऐसी स्थिति बनाई है जिसमें प्रोग्रामर बनने के लिए पर्याप्त लोग अध्ययन नहीं कर रहे हैं , ताकि सरकारों ने अधिक से अधिक छात्रों को उस करियर पथ पर ले जाने के लिए प्रेरित करने के लिए अभियान बनाए हैं।
सॉफ्टवेयर उद्योग की परिपक्वता का एक स्वाद यह है कि सॉफ्टवेयर लाइसेंस जारी रहता है "<companyX> किसी विशेष उद्देश्य के लिए इस सॉफ़्टवेयर की उपयुक्तता के बारे में कोई प्रतिनिधित्व नहीं करता है। यह" जैसा कि "बिना व्यक्त या निहित वारंटी के प्रदान किया गया है।" एक हार्डवेयर निर्माता की कल्पना करें कि उनका उत्पाद किसी विशेष उद्देश्य के लिए उपयुक्त नहीं है। अभी वह अत्याधुनिक है।

— ट्यूलेंस कोर्डोवा
स्रोत

2

निश्चित रूप से 10 से अधिक कंपनियां अपने स्वयं के ओएस बनाने और बनाए रखने में सक्षम हैं, लेकिन कुछ ऐसा करने का चयन करते हैं, क्योंकि अन्य अवसर अधिक आकर्षक हैं।

— बेन वोइगट

@BenVoigt निश्चित रूप से, ओएस बनाने और बनाए रखने के लिए सरासर जटिलता से तुलनात्मक रूप से कम आकर्षक है, जिसके लिए अनुसंधान और विकास के दशकों की आवश्यकता होती है, जो कि उन्हें एक परिपक्व उत्पाद रखने के लिए नब्बे के दशक में नवीनतम रूप से शुरू करना चाहिए था।

— ट्यूलेंस कोर्डोवा

1

आरओआई का "वापसी" पक्ष भी उतना अच्छा नहीं है, क्योंकि बाजार पहले से ही संतृप्त है।

— बेन वोइगट

2

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

— डैनियल आर हिक्स

4

हालांकि कोई विशिष्ट मैट्रिक्स के साथ बहस कर सकता है (यानी, 9.98 के कारक से चीजें बेहतर हुई हैं?), मुझे (एक पुराने टाइमर के रूप में बोलना) ब्रूक्स की टिप्पणी की सामान्य भावना से सहमत होना होगा।

सबसे पहले, वहाँ बहुत कम वास्तव में नई तकनीक का आविष्कार किया गया है शायद 1970 के बाद से। हाँ, एकीकृत सर्किट लंबे समय तक, कम, व्यापक, और ग्लास फाइबर संचार की गति में सुधार हुआ है, लेकिन हर कदम आगे के लिए एक वापस आ गया है।

कंपाइलर तकनीक ने प्रोग्रामर "उत्पादकता" बनाम 1970 में 10x सुधार की अनुमति दी है, जब वास्तविक कोडिंग समय द्वारा विभाजित एक आंकड़े कार्य करते हैं, लेकिन नई या "संशोधित" प्रोग्रामिंग भाषाओं और वातावरण के प्रसार का मतलब है कि औसत प्रोग्रामर अधिक से अधिक खर्च कर रहा है "कैच अप" मोड में समय, और उत्पादक गतिविधि में कम। Apple, Google और Microsoft सभी ने अपने वातावरण में नई और पर्याप्त रूप से असंगत "अपग्रेड" को एक दर पर उतारा, जो नीचे है जो कि उनके सीरफ ... एर, प्रोग्रामिंग ग्राहकों के बीच विद्रोह को उकसाएगा। इसी तरह, HTML / CSS / जावास्क्रिप्ट / जो कुछ भी अधिक जटिल हो रहा है।

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

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

बेशक, वर्षों में जटिलता खत्म हो गई है, आमतौर पर बाजार के योजनाकारों और प्रबंधकों के इशारे पर जिन्हें जटिलता को नियंत्रित करने के लिए कोई सराहना नहीं थी (जो कि सादगी बनाए रखने से अलग है)। मुझे यह महसूस नहीं होता है कि यह अपरिहार्य था, लेकिन इस मामले में एक प्रबंधक के बिना इसे रोकना असंभव था (जैसे ग्लेन हेनरी ने मूल रूप से) भ्रम की ताकतों को पीछे धकेल दिया।

— डैनियल आर हिक्स
स्रोत

2

लेकिन मुझे 20-30 साल पहले मेरे साथ हुई कुछ (और कई अन्य लोगों पर कोई संदेह नहीं) की याद दिलाता है - प्रोग्रामिंग का पीटर सिद्धांत (या शायद प्रोग्रामिंग थर्मोडायनामिक्स का एक 2 नियम) है जो बताता है कि जटिलता अनिवार्य रूप से बढ़ जाती है नासमझी की बात। चीजें कभी सरल नहीं होतीं।

— डैनियल आर हिक्स

3

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

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

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

— zwol
स्रोत