तथ्य यह है कि वे हल करने के लिए दिलचस्प हैं इसका मतलब यह नहीं है कि किसी को उनकी आवश्यकता है

"लोगों का एक समूह लैपटॉप और कागज की एक शीट पर विचार-मंथन कर रहा है," अनसेफश के स्टीफन स्टेफानिक द्वारा फोटो

ऐसे कई कारक हैं जो खराब सॉफ़्टवेयर के निर्माण की ओर ले जाते हैं: उपकरण का विकल्प, टीम संचार, सफलता में डेवलपर्स की व्यक्तिगत उदासीनता, परीक्षण विज्ञान। यह मुझे लगता है कि यह सब मुख्य मूल कारण है: ये काल्पनिक समस्याएं हैं।

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

मान लीजिए कि आप पॉडकास्ट प्रकाशित करते हैं और आपको एक वेबसाइट की जरूरत है जहां आप संबंधित उत्पादों को बेच सकें, विज्ञापन पर पैसा कमा सकें और सबसे महत्वपूर्ण बात, पॉडकास्ट, वीडियो और ब्लॉग प्रकाशित करें।

इस छोटे से वेब एप्लिकेशन की आवश्यकताएं कुछ इस तरह दिख सकती हैं:

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

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

जब आप पहली बार एप्लिकेशन को फ्रीज करते हैं। आप पूछते हैं कि बैनर के प्रकार को कैसे चुनना है - और वे आपको एक बदसूरत, समझ से बाहर यूआई दिखाते हैं। स्टोर में सामानों के लिंक के आधे हिस्से टूट गए हैं या कोई चित्र नहीं हैं, और फेसबुक लैग के माध्यम से लाइव प्रसारण!

लेकिन विकास टीम आपके गुस्से को नहीं समझती है। वास्तव में, उनके दृष्टिकोण से, वे नारकीय कठिन काम करने में सफल रहे।

वे अपनी आत्मा को अनुप्रयोग के निर्माण में लगाते हैं, इसमें अद्भुत विशेषताएं हैं:

• सबसे उन्नत सिफारिश प्रणाली
• सभी ऑडियो स्ट्रीम के लिए रीयल-टाइम टेक्स्ट डिक्रिप्शन एल्गोरिथम
• होम पेज दुनिया भर में 200 एमएस से अधिक तेजी से लोड होता है
• स्ट्रीमिंग प्रोटोकॉल और क्लाइंट लगभग खरोंच से बने होते हैं जब तक आप फेसबुक लाइव पर भरोसा नहीं करना चाहते
• एक सेवा विकसित की गई है जो 20 से अधिक विज्ञापन एक्सचेंजों को एकीकृत करना आसान बनाती है

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

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


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

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

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



एक सॉफ़्टवेयर इंजीनियर अपने लिए जितनी काल्पनिक समस्याएं पैदा कर सकता है, वह उसकी कल्पना और वास्तविक समस्याओं की जटिलता पर निर्भर करता है, जिन्हें हल करने की आवश्यकता होती है।

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

जब समस्याएं बहुत अधिक मूर्ख होती हैं, तो स्मार्ट लोग स्थिति को सुधारने का एक तरीका खोज लेंगे।


लेकिन काल्पनिक समस्याएं न केवल ऊब डेवलपर्स से आती हैं। वे संचार की लंबी श्रृंखलाओं के परिणामस्वरूप भी होते हैं।

जब मैंने सिर्फ एक फ्रीलांसर के रूप में ग्राहकों की तलाश शुरू की, तो मैं अपने विवेक पर संचार का निर्माण नहीं कर सका। इसलिए मुझे सैकड़ों पत्रों के साथ लंबे मेल थ्रेड से निपटना पड़ा, जहां आंतरिक एमवीपी के मामूली विवरणों पर चर्चा की गई। सप्ताह के दौरान लोगों ने परियोजना में हर आवश्यकता को बदल दिया। मेरे पास ऐसे ग्राहक थे जो इस तरह के प्रश्न पूछते थे: "क्या यह ICO के साथ संगत होगा?" या "क्या मैं यहां कुछ AI जोड़ सकता हूं?"

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

आवश्यकताएं बदल जाती हैं क्योंकि किसी ने इरादे को गलत समझा या उक्त ऊब का सामना करने की कोशिश की

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

जब किसी ग्राहक की आवश्यकताओं की सूची इतने सारे लोगों के माध्यम से जाती है, भले ही इन लोगों के पास सबसे अच्छा इरादा हो, लेकिन प्रक्रिया में कुछ अनिवार्य रूप से खो जाता है। कभी-कभी ऐसा होता है क्योंकि मूल आवश्यकता समझ में नहीं आई या बदलने की आवश्यकता नहीं है। शायद विक्रेता ने ग्राहक से कहा: "केवल 39,999 में, हम इसे ऊपर से ब्लॉकचेन पर करेंगे।" वह सहमत हो गया, लेकिन बाकी सभी को यह अनुमान लगाना है कि ब्लॉकचेन पर इसका क्या मतलब है।

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

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

अत्यधिक जटिलता और प्राकृतिक चयन

अक्सर काल्पनिक समस्याओं के प्रकट होने का एक गहरा कारण होता है: ऐसी समस्याएं किसी टीम या कंपनी को बढ़ने में मदद करती हैं, वे इसके काम का एक अभिन्न हिस्सा भी बन सकते हैं।

"जिन लोगों को बाहर निकाला जाता है, उन्हें चुना जाता है, और जटिल समाधानों के लिए प्रोत्साहित किया जाता है, उनमें सरलीकृत लोगों को पेश करने के लिए कोई प्रोत्साहन नहीं होता है।"
- नासिम निकोलस तालेब

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

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

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

ऑनलाइन बैंकिंग की पुरानी समस्या यह है कि बैंकिंग पारिस्थितिकी तंत्र वास्तव में धन विनियोग के अपने स्वयं के पदानुक्रम में उत्कृष्ट है। इसके नेता भ्रष्ट भाषण हैं जो समाज के शरीर से चिपके रहते हैं, लेकिन संगठन के नेता पूरी व्यवस्था की स्थिति को ही दर्शाते हैं।

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

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

"किसी व्यक्ति को कुछ समझना मुश्किल है अगर उसका वेतन उस पर निर्भर करता है जो वह नहीं समझता है!"
- अप्टन सिंक्लेयर

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

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

जैसा कि साधारण प्रबंधक अपनी तानाशाही कल्पनाओं और सत्ता की प्यास के बारे में शिकायत नहीं करते हैं, मध्य-स्तर के प्रबंधक इस तथ्य से मुंह मोड़ लेते हैं कि लागत में कटौती करने के बजाय, वे "हमारी चुस्त चुस्त कार्यप्रणाली में सुधार" के बारे में PowerPoint प्रस्तुतियों पर समय बिताते हैं।

चूंकि टीम के नेताओं को यह भी ध्यान नहीं है कि उनके मालिक भी एक्सेल का उपयोग करना नहीं जानते हैं और सप्ताह में एक-दो बार कार्यालय जाते हैं, तो साधारण प्रबंधक आंखें मूंद लेते हैं जब टीम के नेता और आर्किटेक्ट JRPC के माध्यम से हमारे सिस्टम के बीच की अगली पीढ़ी के बारे में बात करते हैं और Hibernate का उपयोग करते हुए microservices करते हैं। स्प्रिंग ”जब इन लानत MySQL प्रश्नों को एक दिन से अधिक के लिए निष्पादित किया जाता है।

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

यह काल्पनिक समस्याओं को हल करने के लिए एक दुष्चक्र है: सीईओ से जो यह नहीं समझता है कि एक और 30 मिलियन चोरी करने से उसे माता-पिता से प्यार नहीं मिलेगा, जो प्रशिक्षु को यह नहीं समझता है कि 19.13.5 कोणीय-सामग्री-बूटस्ट्रैप पर नया "सबमिट" बटन नहीं बदलेगा उस पासवर्ड को सादे पाठ में संग्रहीत किया जाता है (और कुकीज़ को जांचने के लिए उपयोग किया जाता है)।

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