पुराने सवाल पर एक नया नज़र: क्या आवेदन को खरोंच से फिर से लिखा जाना चाहिए या यह "सबसे खराब रणनीतिक गलती है जिसे एक सॉफ्टवेयर डेवलपर बना सकता है"? यह पता चला है कि परिपक्व कोड आधार के साथ काम करते समय दो से अधिक उत्तर विकल्प होते हैं।

"स्रोत कोड जंग लग रहा है !" - जोएल स्पोल्स्की

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

• कोड बेस के कचरा-प्रतीत भागों में अक्सर सीमा स्थितियों और अजीब बग के बारे में कठिन ज्ञान अर्जित किया जाता है।
  
• पूर्ण परिवर्तन एक दीर्घकालिक उद्यम है जो मौजूदा उत्पाद को बेहतर बनाने से विचलित करता है, जो प्रतियोगियों को ट्रम्प कार्ड देता है।

कई लोगों के लिए, जोएल के निष्कर्ष हठधर्मिता बन गए हैं; एक समय पर उन्होंने मुझ पर बहुत प्रभाव डाला। लेकिन बाद के वर्षों में, मैंने महसूस किया कि कुछ परिस्थितियों में यह अभी भी पूरी तरह से उत्पाद को फिर से बनाने के लिए समझ में आता है। उदाहरण के लिए:

• कभी-कभी एक पुराना कोड आधार वास्तव में पुनर्प्राप्त करने योग्य नहीं होता है, इसलिए यहां तक ​​कि एक सरल उन्नयन के लिए कोड के अन्य भागों में कैस्केडिंग परिवर्तनों की आवश्यकता होती है।
  
• मूल प्रौद्योगिकी समाधान आवश्यक सुधार के साथ हस्तक्षेप कर सकते हैं।
  
• या, मूल तकनीक पुरानी हो सकती है, जिससे योग्य डेवलपर्स को किराए पर लेना मुश्किल (या बहुत महंगा) हो सकता है।

बेशक, वास्तव में बहुत कुछ परिस्थितियों पर निर्भर करता है। हां, कभी-कभी यह पुराने कोड को धीरे-धीरे रिफ्लेक्टर करने के लिए समझ में आता है। और हाँ, कभी-कभी यह सब कुछ फेंकने और शुरू करने के लिए समझ में आता है।

लेकिन यह एकमात्र विकल्प नहीं है । आइए छह कहानियों पर एक नज़र डालें और देखें कि क्या सबक सीखे जा सकते हैं।

---

1. नेटस्केप

ब्राउज़र कोड को स्क्रैच से तीन बार फिर से लिखा गया था

5.0 से 6.0 तक नेटस्केप के भयावह संक्रमण का अवसर था जोएल स्पोल्स्की द्वारा उल्लिखित लेख के लिए और कई लोगों ने आश्वस्त किया कि यह कभी नहीं किया जाना चाहिए।

नेटस्केप नेविगेटर वाणिज्यिक इंटरनेट के शुरुआती वर्षों में 1994 में जारी किया गया था। दो साल बाद, कंपनी ने 3 अरब डॉलर के आईपीओ के साथ डॉट-कॉम युग खोला।

नेटस्केप का पहला प्रमुख प्रतियोगी माइक्रोसॉफ्ट इंटरनेट एक्सप्लोरर था, जो 1996 में जारी किया गया था।

1998 की शुरुआत में, नेटस्केप अभी भी अग्रणी ब्राउज़र था, लेकिन बड़ी कठिनाई के साथ। नेटस्केप एक वाणिज्यिक कार्यक्रम था जो $ 49 के लिए बेचा गया था, और माइक्रोसॉफ्ट ने आईई को मुफ्त में सौंप दिया और विंडोज पर डिफ़ॉल्ट ब्राउज़र के रूप में वितरित किया।



नेटस्केप 4.0 की रिलीज़ के साथ, कंपनी ने घोषणा की कि अगला संस्करण मुफ्त होगा और इसे खुले स्रोत समुदाय द्वारा विकसित किया जाएगा, जिसे मोज़िला द्वारा बनाया और वित्तपोषित किया जाएगा। अपने समय के लिए, यह अनिवार्य रूप से एक अभूतपूर्व कदम था, और नेटस्केप ने इस तरह के साहसिक निर्णय के लिए बहुत सारे समर्थकों को प्राप्त किया। लेकिन वास्तव में, यह "समुदाय" वास्तव में भौतिक नहीं था। जेमी Zinsinski, पहले ब्राउज़र डेवलपर्स में से एक, बताते हैं :

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

टीम इस निष्कर्ष पर पहुंची कि बाहर के डेवलपर्स को परियोजना में कोई दिलचस्पी नहीं थी, जिसमें कोड आधार में गड़बड़ी के कारण शामिल हैं:

कोड बहुत जटिल और बदलने के लिए भ्रमित करने वाला निकला, इसलिए लोगों ने योगदान नहीं दिया ... इसीलिए हमने एक नए इंजन पर स्विच किया। एक क्लीनर, फ्रेशर कोड बेस जिसे समझना और विकास में शामिल होना आसान है।

खरोंच से

इस प्रकार, एक साल बाद, समूह ने एक रिलीज जारी किए बिना 5.0 को छोड़ने का फैसला किया, और खरोंच से संस्करण 6.0 विकसित करने के बारे में निर्धारित किया।

नेटस्केप 6.0 की तैयारी में पूरे दो साल लगे; और इस सब के बाद भी, यह स्पष्ट था कि ब्राउज़र कच्चा था। न्यूयॉर्क टाइम्स के स्तंभकार डेविड पोग के अनुसार, ब्राउज़र एक पूर्ण मिनट (!) और रैम का उपभोग करता था। इसमें कई सरल प्रयोज्य सुविधाओं का अभाव था जो पिछले संस्करणों में थे:

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

लेकिन यह लगभग अप्रासंगिक था, क्योंकि नेटस्केप ने तीन साल में जो काम किया, वह इंटरनेट एक्सप्लोरर ने शेष बाजार हिस्सेदारी पर कब्जा कर लिया:


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

1999 में, जब ब्राउज़र रिडिजाइन पूरे जोरों पर था, तो AOL ने नेटस्केप को $ 10 बिलियन में अधिग्रहित कर लिया। नेटस्केप 6.0 के रिलीज़ होने के ठीक दो साल बाद, नेटस्केप के एओएल विभाजन को नष्ट कर दिया गया।

नेटस्केप द्वारा बनाया गया ओपन सोर्स समुदाय मोज़िला 2002 में फ़ायरफ़ॉक्स ब्राउज़र को एक और क्लीन-शीट प्रोजेक्ट के रूप में मौजूद और लॉन्च करना जारी रखेगा। फ़ायरफ़ॉक्स Microsoft को छोड़ने वाले कुछ उपयोगकर्ताओं को वापस करने में कामयाब रहा।

लेकिन नेटस्केप, एक व्यवसाय के रूप में, मर गया है (माइक्रोसॉफ्ट एओएल के साथ 2012 के सौदे के परिणामस्वरूप नेटस्केप के बौद्धिक संपदा के अवशेषों को दफन कर देगा)।

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

निष्कर्ष

कुछ का मानना ​​है कि खरोंच से पुनर्लेखन एक आपदा नहीं थी। अंत में, इसके लिए, गेको इंजन और फ़ायरफ़ॉक्स ब्राउज़र अंततः दिखाई दिए।

लेकिन हम सभी को आईई 6 के अंतहीन, घुटन वाले एकाधिकार के तहत वेब प्रौद्योगिकियों में ठहराव के वर्षों को सहना पड़ा, जबकि हम एक नए ब्राउज़र की तलाश कर रहे थे जिसने उद्योग में जीवन की सांस ली। और IE6 युग का अंत फ़ायरफ़ॉक्स द्वारा नहीं किया गया था, लेकिन Google क्रोम।

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

---

2. बेसकैंप

2000 के दशक की शुरुआत में, शिकागो स्थित वेब डिज़ाइन स्टूडियो जिसे 37signals कहा जाता था, अपने प्रभावशाली और अक्सर विवादास्पद ब्लॉग के लिए प्रसिद्ध हो गया, जिसके संस्थापक जेसन फ्राइड और DHH थे ।

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




37signals FedEx डिलीवरी फॉर्म (ऊपर) का रीडिज़ाइन लगभग दो दशक बाद भी वास्तविक डिजाइन से बेहतर है

कंपनी के पास आंतरिक उपयोग के लिए एक परियोजना प्रबंधन प्रणाली थी, जिसे उन्होंने 2004 में बेसकैंप नामक सास सेवा के रूप में जारी किया था।

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

कुछ वर्षों में तेजी से आगे, बेसकैंप के पास आधे मिलियन खुश उपयोगकर्ता हैं, हर महीने भुगतान आते हैं, लेकिन जेसन और डेविड को चिंता होने लगी।

कुछ साल पहले डेविड ने एक बिजनेस ऑफ सॉफ्टवेयर कॉन्फ्रेंस में यह कहानी बताई थी। उन्होंने स्वीकार किया कि वह जोएल स्पोलस्की से प्रभावित थे और उनका मानना ​​था कि पुनर्लेखन सॉफ्टवेयर कंपनी को मार देगा। इसके अलावा, चंचल आंदोलन की लोकप्रियता के संबंध में शालीनता और धार्मिकता का एक निश्चित तत्व था :

[I] पूरी तरह से ट्रान्सेंडेंट सॉफ्टवेयर के विचार में लीन था ... असीम रूप से प्लास्टिक कोड। असीम रूप से मूल्यवान विरासत। आप कुछ भी बदल सकते हैं, किसी भी कार्यक्रम, किसी भी कोड को फिर से लिख सकते हैं ... यदि सॉफ़्टवेयर को बदलना मुश्किल है, तो यह आपकी अपनी गलती है। आप एक गरीब प्रोग्रामर हैं, इसलिए आपको सुधार करने की आवश्यकता है।

हालांकि, "सात वसा वर्षों" के बाद कंपनी ने खुद को एक विचित्र रूप में पाया - और समस्या का तकनीकी ऋण से कोई लेना-देना नहीं था ।

सोने की हथकड़ी

यह सब इस तथ्य से शुरू हुआ कि लोगों में उत्साह की कमी देखी गई। न केवल एक प्रमुख उत्पाद पर काम करने के लिए पर्याप्त प्रेरणा नहीं थी, बल्कि वे खुद भी विशेष रूप से अपने कार्यक्रम का उपयोग नहीं करते थे।

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

मौजूदा ग्राहकों को खुश करने की इच्छा के कारण, उत्पाद विकास में रुक गया, जिसने नए उपयोगकर्ताओं को आकर्षित करने से रोका। इससे सीधे तौर पर कारोबार को खतरा नहीं था, बल्कि दीर्घकालिक खतरा पैदा हो गया। DHH रूपक के साथ स्थिति की तुलना टपका हुआ बाल्टी से करता है:

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

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

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

डेवलपर्स ने एक लाभदायक उत्पाद को सोने की हथकड़ी की एक जोड़ी के रूप में मानना ​​शुरू किया:

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

स्पॉयलर: बेसकैंप को खरोंच से फिर से लिखा गया था, और यह बहुत अच्छा निकला। इसमें लगभग एक साल का समय लगा, और बासकैंप 2 के रिलीज होने के तुरंत बाद, नए पंजीकरणों की संख्या दोगुनी हो गई।

मुझे लगता है कि उन्होंने दो मुख्य चीजें कीं।

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

क्या हम यह सोचने के लिए प्रतिबद्ध हैं कि २००३ के विचार अभी भी २०११ के सर्वश्रेष्ठ विचार हैं? हां, मुझ पर अहंकार का आरोप लगाया गया था, लेकिन 2008 में सभी भाप निकले।

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

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

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

सूर्यास्त को हानिकारक माना जाता है

लेकिन उन सैकड़ों मौजूदा उपयोगकर्ताओं के बारे में क्या है जिनके पास अपना पसंदीदा खिलौना है? यह हमें दूसरी दिलचस्प बात पर लाता है जो डेवलपर्स ने किया था: उन्होंने पुराने उत्पाद को रखा था।

डेविड ने "सूर्यास्त सॉफ्टवेयर" शब्द पर शानदार सवारी की थी:

कोई व्यक्ति "सनसेट" नामक एक सुंदर व्यंजना के साथ आया था ... सॉफ़्टवेयर के विनाश को "सूर्यास्त" कहें ... जैसे सभी उपयोगकर्ता समुद्र तट पर हैं - और भावना के साथ देखते हैं कि उनकी जानकारी गायब हो जाती है। यह महान है!

एकमात्र लोग जो "सूर्यास्त" में विश्वास करते हैं, वे हैं जो इसे कहते हैं। एक भी उपयोगकर्ता जो कभी सूर्यास्त की अवधि से गुजरता था, वापस आता है और कहता है, "ओह, यह सुंदर था।" वे वापस आते हैं और कहते हैं: “धिक्कार है! मैंने यहाँ कई साल काम किया! .. और अब आप मुझे रोल करने जा रहे हैं! "

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

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

डेविड ने बेसकैंप क्लासिक की तुलना लीका एम 3 से की है: कैमरे का उत्पादन 1967 से नहीं हुआ है, लेकिन लीका ने अपने दिनों के अंत तक इसे बनाए रखने और मरम्मत करने का वादा किया है (फोटो: Dnalor 01 )

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

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

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

लेकिन "लेकिन" का एक बहुत कुछ है। क्या यह महंगा नहीं है? कई संस्करणों का समर्थन करने के लिए बहुत प्रयास करते हैं? सुरक्षा के बारे में क्या? आउटडेटेड कोडबेस के बारे में क्या? मैं क्या कह सकता हूं। हम सिर्फ ग्राहकों की परवाह करते हैं, भले ही वे हमारे शेड्यूल के अनुसार अपडेट न हों।

निष्कर्ष

व्यक्तिगत रूप से, यह मॉडल वास्तव में मेरे लिए प्रेरणादायक है।

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

बेशक, असीम रूप से लंबे समय के लिए कई संस्करणों का समर्थन करना एक मूल्य पर आता है; लेकिन जैसा कि डेविड कहते हैं:

यह स्वतंत्र नहीं है। बिल्कुल नहीं। यह एक मूल्यवान उत्पाद है और निश्चित रूप से, समर्थन मुक्त नहीं है। लेकिन यह इसके लायक है।

---

3. विजुअल स्टूडियो और वीएस कोड

नोट: हिपस्टर आइकन

Microsoft ने अन्य प्लेटफार्मों पर डेवलपर्स तक पहुंचने के लिए VS कोड बनाया।

आपको याद होगा कि लंबे समय के लिए, Microsoft ने "सभी या कुछ भी नहीं" की पेशकश की है। यदि आपने Visual Studio का उपयोग किया है, तो आपने .NET में काम किया होगा, और इसके विपरीत। इसने सॉफ्टवेयर समुदाय को दो बड़े, ज्यादातर पारस्परिक रूप से अनन्य शिविरों में विभाजित किया है - सभी के लिए।

शांत लोगों से अपील

स्टीव बाल्मर के वर्षों में स्थिति वापस बदलना शुरू हुई: याद रखें कि एएसपीनेट डेवलपर्स द्वारा jQuery का आविष्कार नहीं करने का निर्णय कितना जोर से हुआ!

सत्या नडेला के सीईओ के मुख्य कार्यों में से एक अपने "फेंसर्ड गार्डन" के बाहर डेवलपर्स से संपर्क करना था।

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

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

तो उस अवरोध को तोड़ने और कहने के लिए VS कोड बनाया गया था, “सच में पता है क्या, दोस्तों? हमारे पास अभी भी आपके लिए कुछ उपयोगी है। ”

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

इसलिए, Microsoft ने बैकवर्ड संगतता की गारंटी के बिना, खरोंच से शुरू किया।

वास्तव में, खरोंच से काफी नहीं: माइक्रोसॉफ्ट के पास पहले से ही कुछ महत्वपूर्ण भाग थे, जैसे कि ब्राउज़र में मोनाको संपादक। और चूंकि VS कोड एक Node.js एप्लिकेशन है (टाइपस्क्रिप्ट में लिखा गया है और इलेक्ट्रॉन में लॉन्च किया गया है), उन्होंने जावास्क्रिप्ट पारिस्थितिकी तंत्र के समृद्ध संसाधनों का लाभ उठाया।

ओपन सोर्स वीएस कोड, हल्का, तेज, एक्स्टेंसिबल - जो एक Microsoft उत्पाद के लिए आश्चर्य की बात है - उन्नत युवाओं के लिए एक ट्रेंडी प्रोग्रामिंग टूल बन गया है।


वीएस कोड जेएस-हिपस्टर्स के लिए मुख्य संपादक बन गया (रिपोर्ट के जावास्क्रिप्ट सर्वेक्षण राज्य से आरेख , 2018 )

दोनों उत्पाद अभी भी सक्रिय विकास के अधीन हैं, और ऐसा कोई संकेत नहीं है कि Microsoft विज़ुअल स्टूडियो को बंद करने का इरादा रखता है।

निष्कर्ष

नेटस्केप के विपरीत, माइक्रोसॉफ्ट वास्तव में वीएस कोड के आसपास एक सक्रिय ओपन सोर्स समुदाय बनाने में कामयाब रहा। इसने उत्पाद को बेहतर बनाने के लिए डेवलपर्स के प्रयासों को बढ़ाया है।


सभी ओपन सोर्स प्रोजेक्ट्स में, विजुअल स्टूडियो कोड, GitHub पर सितारों की संख्या के संदर्भ में 13 वें स्थान पर है - संयोग से, लिनक्स के नीचे!

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

एक अन्य महत्वपूर्ण कारक: Microsoft ने उच्च गुणवत्ता वाले एक्स्टेंसिबिलिटी मॉडल के साथ VS कोड प्रदान किया है , जिसके परिणामस्वरूप समुदाय ने पहले से ही 10,000 एक्सटेंशनों के बारे में लिखा है।

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

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

---

4. जीमेल और इनबॉक्स

नोट:

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

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

दो इंटरफेस, एक सेवा

इनबॉक्स और जीमेल ने एक ही बैकएंड पर काम किया। वास्तव में, ये एक ही सेवा के लिए अलग-अलग उपयोगकर्ता इंटरफ़ेस हैं, और आप अपनी इच्छानुसार आगे और पीछे स्विच कर सकते हैं। इसके अपने फायदे और नुकसान थे: यदि इनबॉक्स में फ़ंक्शन की कमी होती है (कहते हैं, एक छुट्टी के लिए एक जवाब देने वाली मशीन), तो आप हमेशा जीमेल पर लौट सकते हैं और आपको जो आवश्यक हो उसे कॉन्फ़िगर कर सकते हैं, हालांकि आगे और पीछे स्विच करना अजीब लग रहा था।

हालांकि, थोड़ी देर बाद, इनबॉक्स में सुधार होना बंद हो गया - यह स्पष्ट हो गया कि Google अब इसमें संसाधनों का निवेश नहीं कर रहा था। स्वाभाविक रूप से, लॉन्च के चार साल बाद, Google ने इनबॉक्स के सूर्यास्त की घोषणा की ।



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

लेकिन इनबॉक्स से सब कुछ जीमेल में स्थानांतरित नहीं किया गया था: उदाहरण के लिए, लोगों को "विराम मोड" (स्नूज़िंग) के लिए उपयोग किया जाता है कि इसके बिना वे सचमुच शारीरिक रूप से पीड़ित होते हैं।

निष्कर्ष

इनबॉक्स ने Gmail डेवलपर्स को उपयोगकर्ताओं के विशाल बहुमत के वर्कफ़्लो को बाधित किए बिना सुविधाओं के साथ प्रयोग करने में सक्षम बनाया ।

हालांकि, एक ही बैकएंड पर दोनों संस्करणों की सेवा करते हुए , जीमेल ने नवाचार पर गंभीर प्रतिबंध लगा दिए हैं ।

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

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

मुझे लगता है कि कई लोगों के लिए, संक्रमण बहुत आसान होता, अगर, इनबॉक्स को बंद करने से पहले, उसके सभी कार्यों को जीमेल में एकीकृत किया गया था।

---

5. फोगबुग और ट्रेलो

ध्यान दें:

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

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

फोगबुग बहुत लोकप्रिय हो गया है, खासकर उन डेवलपर्स के बीच, जिन्होंने मेरे उदाहरण में, जोएल के ब्लॉग को पढ़ा और उनकी सलाह को दिल से लगा लिया। मेरी कंपनी ने कई वर्षों तक प्रणाली का उपयोग किया, यह अपने समय के लिए एक महान उत्पाद था।

फोगबुग को मूल रूप से क्लासिक एएसपी पर लिखा गया था, जो विंडोज सर्वर पर काम करता था। जब ASP.NET बाहर आया, तो जोएल ने बताया कि वह अपडेट करने की जल्दी में क्यों नहीं था ।

लिनक्स सर्वर पर FogBugz को स्थापित करने के लिए, एक कंपनी इंटर्न ने क्लासिक ASP को PHP में बदलने के लिए एक थीस्ल कंपाइलर लिखा। 2006 तक, थीस्ल एक मालिकाना प्रोग्रामिंग भाषा में विकसित हो गई थी जिसे वासाबी कहा जाता था, जिसे एएसपी, पीएचपी और क्लाइंट-साइड जावास्क्रिप्ट में संकलित किया गया था।

वसाबी की अजीब कहानी

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

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

अपनी भाषा में लिखना बिल्कुल सीमा से परे है। यह एक जहरीला समाधान है जो जोएल के पिछले उत्कृष्ट और मजबूत सॉफ्टवेयर विकास युक्तियों के साथ ऐसा है जो लोगों को वास्तव में लगा कि वह मजाक कर रहा है।

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

"तकनीकी ऋण और पवन की खोज" नामक एक पर्याप्त निबंध में वसाबी पर चिंतन करते हुए , पूर्व फॉग क्रीक इंजीनियर टेड अनंगस्ट ने बिना नक्शे के यात्रा करने की प्रक्रिया की तुलना की:

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

कहीं बोस्टन में, या नोवा स्कोटिया में, आप अंततः रुक जाते हैं और अपनी पसंद के बारे में सोचते हैं। शायद इस सड़क से लंदन नहीं जाता? गैलरी से दूर आप हँसी सुन सकते हैं: “हा हा हा, इन मोरों को देखो। वे इंग्लैंड और न्यू इंग्लैंड के बीच अंतर नहीं देखते हैं। इन मूर्खों को एक नक्शा दें। ” लेकिन यह ठीक समस्या है: आपके पास कार्ड नहीं है। मानचित्र ऐसे लोगों द्वारा बनाए जाते हैं जो लगभग परिभाषा से नहीं जानते हैं कि वे कहां जा रहे हैं।

किसी भी मामले में, एक अन्य पूर्व फॉग क्रीक डेवलपर जैकब क्रॉल बताते हैं , समाधान ने आज की विकास गति के लिए कल की स्थिरता को त्याग दिया। और 2010 तक, इस ऋण के खाते आने शुरू हो गए।

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

विभक्ति बिंदु

तब तक, फोगबुग पहले से ही दस साल का था: यह एक परिपक्व और स्थिर उत्पाद था। एक साइड प्रोजेक्ट के रूप में, जोएल ने जेफ एटवुड के साथ मिलकर स्टैक ओवरफ्लो लॉन्च किया (जाहिर है, जेफ का उड़ा हुआ सिर तब से ठीक हो गया था)।

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

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

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

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

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

वह दो काम करने का फैसला करता है। सबसे पहले, FogBugz में सभी सुविधाएँ जोड़ें:

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

दूसरे, एक कॉर्पोरेट बिक्री टीम बनाएं । जोएल स्वीकार करता है कि वह यहां मजबूत नहीं है, और इस कार्य को अप्रिय पाता है।

मुझे नहीं पता कि इन उपायों ने कैसे काम किया। जोएल ने आखिरी बार मई 2010 में अपने ब्लॉग पर फोगबुग का उल्लेख किया, एक नए संस्करण की संक्षिप्त घोषणा की।

नई उम्मीद

और यही हुआ:

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

इसलिए, उन्हें दो टीमों में विभाजित किया गया था, जिनमें से प्रत्येक ने एक नए उत्पाद का प्रोटोटाइप बनाया था। जीतने का विचार एक कन्नन बोर्ड की भावना में बनाया गया था - एक वास्तविक ऑफ़लाइन बोर्ड जो अक्सर सॉफ्टवेयर विकास परियोजनाओं में उपयोग किया जाता है: यह आमतौर पर एक बोर्ड पर कॉलम में व्यवस्थित नोट्स जैसा दिखता है।

जोएल ने इस कार्यक्रम को फोगबुग की तुलना में उच्च स्तर पर एक प्रबंधन उपकरण के रूप में पेश किया:

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

ट्रेलो को बनाते समय, फॉग क्रीक डेवलपर्स को आधुनिक तकनीकों का उपयोग करने का मौका मिला:

हम उन्नत तकनीक का उपयोग करते हैं, इसलिए यह बलिदान के बिना नहीं है। हमारे डेवलपर घाव पूरे MongoDB, WebSockets, CoffeeScript और Node में बिखरे हुए हैं। लेकिन अब उनकी दिलचस्पी है। आज के व्यस्त श्रम बाजार में, प्रतिभाशाली प्रोग्रामर बहुत कुछ तय करते हैं कि वे क्या काम करना चाहते हैं। यदि आप उन्हें एक दिलचस्प उत्पाद देते हैं ... तो वे इसे पसंद करेंगे और उन्हें अपनी कंपनी से प्यार होगा।

ट्रेलो ने शुरू से ही प्लग इन का समर्थन किया, इसलिए तीसरे पक्ष के डेवलपर्स ने मदद करना शुरू किया:

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

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

जबकि FogBugz एक ऊर्ध्वाधर उत्पाद था - एक विशिष्ट बाजार आला के लिए उन्मुख - Trello एक क्षैतिज उत्पाद था जो किसी भी चीज़ के लिए उपयुक्त था। जोएल फॉग क्रीक के "क्षैतिज गति" को उस बिंदु पर सही मानते हैं:

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

बहुत बड़ी संख्या में उपयोगकर्ताओं को जल्दी से स्केल करने के लिए, शुरुआत में ट्रेलो को मुफ्त में पेश किया गया था। बाद में एक बिजनेस प्लान पेश किया।

2014 में, ट्रेलो को एक स्वतंत्र कंपनी के रूप में चुना गया । तीन साल बाद, इसने 17 मिलियन से अधिक उपयोगकर्ताओं के साथ $ 425 मिलियन की बिक्री की । विडंबना यह है कि खरीदार एटलसियन था, जो फॉग क्रीक का पुराना शत्रु था।

इस बीच, घर लौट रहा था

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

इसी समय, फोगबुग सिस्टम अस्पष्टता में जम गया। 2017 में, किसी ने फैसला किया कि फोगबुग एक मूर्खतापूर्ण नाम है, और इंजीनियरिंग का प्रयास उत्पाद को मैन्क्राफ्ट के रूप में पुन: प्रस्तुत करने में चला गया। एक साल बाद - कुछ महीने पहले - फॉग क्रीक ने एक छोटी सी कंपनी DevFactory को उत्पाद बेचा, जिसने तुरंत ही FogBugz नाम लौटा दिया ।

सीईओ अनिल दाश के नेतृत्व में, फॉग क्रीक एक एकल-उत्पाद कंपनी बन गई और इसका नाम बदलकर ग्लिच रख दिया गया ।

निष्कर्ष

इस बारे में मेरे पास बहुत सारे विचार हैं।

इतिहास को समझने की कुंजी यह है कि फॉग क्रीक हमेशा बग ट्रैकिंग के बारे में इतना ध्यान नहीं रखता था क्योंकि यह प्रोग्रामर्स को सशक्त बनाने के बारे में था - इसकी शुरुआत

मुख्य कार्य: आरामदायक काम करने की स्थिति बनाना। हमने कर्मचारियों के लिए व्यक्तिगत खाते बनाए, उन्होंने केवल प्रथम श्रेणी में उड़ान भरी, सप्ताह में 40 घंटे काम किया, मुफ्त दोपहर का भोजन, एरोन कुर्सियां ​​और सर्वश्रेष्ठ कंप्यूटर प्राप्त किए। हमने अपने सरल फार्मूले को दुनिया के साथ साझा किया: उत्कृष्ट काम करने की स्थिति → उत्कृष्ट प्रोग्रामर → उत्कृष्ट सॉफ्टवेयर → लाभ!

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

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

हालांकि, थोड़ा दुख की बात है कि यह सब कैसे फोगबुग के लिए समाप्त हो गया। मुझे नहीं लगता कि फॉग क्रीक के डेवलपर्स बिक्री से पहले आखिरी दिनों में विशेष रूप से खुश थे।

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

हालाँकि, पिछले कुछ वर्षों में इस उत्पाद के निर्माण और उपयोग में शामिल सभी लोगों का भावुक हिस्सा अधिक सम्मानजनक रूप से "विरासत का सम्मान" करना पसंद करेगा।

---

6. फ्रेशबुक और बिलस्प्रिंग

नोट: गुप्त ऑपरेशन आइकन

लेख मेरी अपेक्षा से अधिक बढ़ गया है, लेकिन मैं इस कहानी को एक तरफ नहीं छोड़ सकता। पकड़ो, एक अप्रत्याशित मोड़ होगा।

अगर आपने इसे सुना है तो मुझे रोकें

2000 के दशक की शुरुआत में, माइक मैकडैरमेंट के पास एक छोटी डिज़ाइन फर्म थी। उन्होंने फैसला किया कि लेखांकन सॉफ्टवेयर बहुत जटिल था, इसलिए उन्होंने बिलिंग के लिए वर्ड और एक्सेल का उपयोग किया।

एक मामले तक सब कुछ ठीक रहा :

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

माइक एक डिजाइनर है, एक प्रोग्रामर नहीं है, लेकिन वह और दो सह-संस्थापकों ने कई लोगों के लिए एक उपकरण को एक साथ रखने में कामयाब रहे, जो इसे उपयोग करने के लिए प्रति माह $ 10 का भुगतान करते हैं। व्यवसाय को माता-पिता के घर के तहखाने को छोड़ने में लगभग चार साल लग गए ।

कार्यक्रम की 10 वीं वर्षगांठ तक (क्या यह परिचित लगता है?) फ्रेशबुक 10 मिलियन से अधिक उपयोगकर्ताओं और 300 कर्मचारियों के साथ एक लाभदायक कंपनी बन गई है।

लेकिन एक समस्या थी। जब तक कंपनी "वास्तविक" प्रोग्रामरों को रखने में कामयाब रही, तब तक उनके पास "संस्थापक कोड" की एक लाख लाइनें थीं। एक बाहरी विश्लेषक ने कोडबेस की समीक्षा की और निष्कर्ष निकाला:

“अच्छी खबर यह है कि आपने सबसे कठिन काम हल कर लिया है। आपको पता चला कि व्यवसाय कैसे बनाया जाता है, और आपके पास एक उत्पाद है जिसे लोग पसंद करते हैं। बुरी खबर यह है कि आप लोग तकनीक के मामले में खराब हैं । ”

इससे भी महत्वपूर्ण बात, एक मौजूदा उत्पाद में मौजूदा विचारों को लागू करना असंभव था:

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

MacDerment पारंपरिक ज्ञान से परिचित है जिसे आप किसी सिस्टम को स्क्रैच से दोबारा नहीं लिख सकते हैं:

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

इस प्रकार, उन्होंने खरोंच से सिस्टम को फिर से लिखने के बिना गंदगी को साफ करने के कई प्रयास किए; लेकिन "टायरों की जगह पर चलना" संभव नहीं था।

आगे जो हुआ वो आपको हैरान कर सकता है

McDermint का दौरा गुप्त रूप से "प्रतियोगी" फ्रेशबुक बनाने के विचार से हुआ था।

उन्होंने बिलवेयर नाम से डेलावेयर में एक पूरी तरह से नई कंपनी की स्थापना की। उसकी अपनी वेबसाइट, ब्रांड और लोगो था। दोनों कंपनियों को न जोड़ने की कोशिश करते हुए, उन्होंने एक बाहरी वकील को उसके लिए नए दस्तावेज़ विकसित करने का निर्देश दिया।

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

“आपके पास साढ़े चार महीने हैं। यदि आप बाजार में प्रवेश करते हैं, तो अधिक पैसा प्राप्त करें। अन्यथा, अंत। "

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

पहले वर्ष के अंत में, बिलस्प्रिंग ने चार्ज करना शुरू कर दिया। कुछ बिंदु पर, नए उत्पाद को गुणवत्ता का अप्रत्याशित मूल्यांकन प्राप्त हुआ :

"एक व्यक्ति ने फ्रेशबुक से सदस्यता समाप्त करने और हमारी नई कंपनी में जाने का आह्वान किया," मैकडरमिंट कहते हैं। "यह एक महान दिन था।"

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

धीरे-धीरे, "क्लासिक" फ्रेशबुक के ग्राहकों को नए संस्करण में भर्ती किया गया था, लेकिन वे हमेशा पुराने वाले पर लौट सकते थे यदि वे चाहते थे।

निष्कर्ष

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

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

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

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

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

यह सब थोड़ा चरम लगता है। शायद ऐसे उपाय आवश्यक नहीं थे। लेकिन यह एक स्मरण है कि दांव कितना गंभीर है।

---

कुछ विचार

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

लेकिन सलाह बताती है कि अंत में हमें एक मूल उत्पाद और नई सुविधाओं का एक सेट मिलता है।

लेकिन क्या होगा अगर आप कार्यक्षमता को दूर करना चाहते हैं? या कुछ विकल्प को पूरी तरह से अलग तरीके से लागू करें? क्या होगा अगर अनुभव एक मौलिक नए दृष्टिकोण के विचारों के साथ आया?

इन कहानियों से मेरा निष्कर्ष यह है: जैसे ही आप समझते हैं कि वर्तमान संस्करण काल्पनिक आदर्श से बहुत अलग है , नए संस्करण को प्रतिस्थापन के रूप में जारी नहीं किया जाना चाहिए , लेकिन वर्तमान के समानांतर ।

जब खरोंच से सब कुछ फिर से लिखने के विचार हैं, तो शायद आपको अन्य प्रश्न पूछना चाहिए। शायद अपना खुद का प्रतियोगी बनाएं? यदि मेरा उत्पाद FogBugz है, तो मेरा Trello क्या होगा? यदि यह Visual Studio है, तो मेरा VS कोड कैसा दिखेगा?

यदि आप नेटस्केप पर Spolsky के लेख और बास्कैम्प के बारे में DHH पोस्ट की तुलना करते हैं, तो वे एक बात पर सहमत होते हैं: विरासत का मूल्य है।

अच्छी खबर यह है कि आपको इस मूल्य को नया करने के लिए फेंकने की आवश्यकता नहीं है।