सॉफ्टवेयर विकास में सबसे खराब झूठी अर्थव्यवस्थाएं क्या हैं? [बन्द है]

Question

सॉफ़्टवेयर उद्योग में प्रचलित सबसे खराब झूठी अर्थव्यवस्थाएं (जो पैसे बचाने के तरीके हैं जो अंततः उन्हें बचाने की तुलना में अधिक खर्च होती हैं) और आप उनका मुकाबला कैसे करते हैं?

Comments

:( मैंने इनमें से कई को अक्सर देखा है।

— टोनी

संबंधित प्रोग्रामर

— .stackexchange.com

@ कैसी: यह थोड़ा संबंधित है, लेकिन पूरी तरह से नहीं। आपने जो लिंक दिया है, वह सीधे पैसे से संबंधित है, जबकि इस सवाल का जवाब यहां पैसे और विश्वास के साथ है। उदाहरण, मेरा उत्तर देखें: programmers.stackexchange.com/questions/19573/…

— गण

क्या आपने अभी मेरी कंपनी का दौरा किया .. कोई बात नहीं; पी

— pramodc84

@ मर्क - एक अच्छा सवाल लगता है, इसके लिए जाओ। हालांकि कुछ और बारीकियां अच्छी हो सकती हैं।

— जॉन हॉपकिंस

Answer 1

तकनीकी ऋण

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

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

Comments

मैं एक दिन के लिए मैंने प्रबंधन स्टॉप डेवलपर्स (2 से 3) को देखा है, तो एक तैनाती विशेषज्ञ को खर्च को ठीक करने के बजाय कुछ ठीक करने (और उत्पाद के जीवन चक्र पर कई बार ऐसा करने) की गिनती नहीं कर सकते हैं 4 दिन इसे सही करने के लिए। बहुत बढ़िया जवाब।

— देवसोलो

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

— JBRWilkinson

हमें "यह एक हैक है, डेमो के बाद प्रतिस्थापित करें" जैसी टिप्पणियों के साथ कोड मिल गया है जो कि 3 से 5 साल तक चलने के लिए आधार में रहा है। किसी को यह भी याद नहीं है कि यह इस बिंदु पर किया गया था, इसलिए कोई भी इसे तब तक नहीं पाता है जब तक कि कोई (मुझे) बग को ठीक नहीं करता है और इसके पार नहीं चलता है। कहने की जरूरत नहीं है, इस ऑब्जेक्ट सबक ने मुझे पहली बार सही करने के लिए बहुत अच्छी तरह से सिखाया है अगर मैं किसी भी तरह से ऐसा करने में सक्षम हूं।

— कोडेक्सअर्केनम

और ईमानदारी से, मैं लगातार समय की कमी से हैरान हूं, यह अल्पकालिक समय भी नहीं बचाता है!

— पीटरअलेनवेब

@ जॉर्ग - हुह? "तकनीकी ऋण और डिज़ाइन ऋण पर्यायवाची हैं, निओलिस्टिक रूपकों ने स्लैपडश सॉफ़्टवेयर आर्किटेक्चर और जल्दबाजी सॉफ्टवेयर विकास के अंतिम परिणामों का उल्लेख किया है।" en.wikipedia.org/wiki/Technical_debt यह ठीक वही है जिसका मैं उल्लेख कर रहा हूं। एक अधिक विशिष्ट शीर्षक शायद "इसे पुन: प्रस्तुत करने के इरादे के बिना तकनीकी ऋण में वृद्धि" हो सकता था, लेकिन, इस स्थिति में कई लोग खुद को बताते हैं कि वे वास्तव में चुकाने का इरादा रखते हैं (लेकिन नहीं), और मैं एक छिद्रपूर्ण शीर्षक चाहता था । शीर्ष पर बोल्ड टेक्स्ट । "तकनीकी ऋण" एक अच्छा पर्याप्त सारांश लग रहा था।

— इनामाथी

Answer 2

1 के बजाय 2 सस्ते डेवलपर्स किराए पर लेना वास्तव में बहुत अच्छा है। (एक ही कीमत के लिए)

Comments

यह कम से कम वास्तविकता में एक आधार लगता है; ध्यान रखें कि गैर-तकनीकी लोग यह नहीं बता सकते हैं कि कौन महान डेवलपर हैं (इसलिए वे एक वास्तविक सुपरस्टार की तुलना में सिर्फ दो बार एक यादृच्छिक, परामर्श से अधिक भुगतान करने की संभावना रखते हैं)।

— इनामाथी

या दुख की बात है, सिर्फ 1 सस्ता एक काम पर रखने ...

— DevSolo

... या एक गुरु को किराए पर लेना जहाँ दो

— डमियां

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

— पीटर बॉटन

10x या 100x प्रोग्रामर पैसे के लिए इस तरह के अविश्वसनीय अविश्वसनीय मूल्य हैं; वे केवल भुगतान किया हो सकता है 1.5 शायद 2x। जैसा कि माइकल लोप (रैंड्स इन रिपोज) कहते हैं, यदि आप अपने पूरे करियर में इनमें से किसी एक को ही काम पर रखते हैं, तो यह एक शुद्ध जीत है।

— टिम विस्क्राफ्ट

Answer 3

मेरा उदाहरण निमशिम्पस्की के उदाहरण के पूर्ण विपरीत होगा , अर्थात्:

घर में कुछ ऐसा विकसित करने की कोशिश की जा सकती है जिसे ऑफ-द-शेल्फ खरीदा जा सके।

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

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

Comments

सिर्फ इसलिए कि यह हो सकता है, इसका मतलब यह नहीं होना चाहिए। एक बुनियादी सीएमएस, अच्छी तरह से हाँ क्यों पहिया को सुदृढ़ करें। लेकिन जब आप बड़े पैमाने पर सिस्टम और मॉडलिंग की जटिल व्यावसायिक प्रक्रियाओं के बारे में बात करना शुरू करते हैं - तो एक वर्ग छेद में गोल खूंटी को क्यों आज़माएं और फिट करें? खासकर यदि आपके पास घर में मौजूदा डेवलपर्स और कौशल हैं।

— निमचिम्प्सकी

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

— जॉन हॉपकिंस

@NimChimpsky यदि युक्ति को एक bespoke विकास की आवश्यकता है, तो यह ठीक है - यह हमें नौकरियों में रखता है :) समस्या तब आती है जब लोग पहले यह नहीं जांचते हैं कि क्या पहले से ही विकसित कुछ है जो बिल को फिट करता है और सीधे विकास में गोता लगाता है। थोड़ा शोध बहुत आगे बढ़ सकता है!

— डैन डिप्लो

पहिया को क्यों मजबूत करें? क्योंकि आप एक पहिया इंजीनियर हैं। या क्योंकि आपका पहिया अगले आदमी के पहिये से बेहतर है। या क्योंकि पहिया फिट नहीं है। देखें: mostlymaths.net/2010/03/...

— डेरेक

जहां मैं काम करता हूं लगभग सब कुछ ओटीएस खरीदा जा सकता है - और लगभग सब कुछ घर में फिर से आविष्कार किया गया है क्योंकि हमारे फियरलेस लीडर्स (टीएम) के अनुसार "हमारा वातावरण इतना जटिल है कि बाजार पर कुछ भी संभवतः इसे संभाल नहीं सकता है"। Pfeh! लेकिन क्या हे - यह बिलों का भुगतान करता है। हमने कल बताया कि हमारे सॉफ़्टवेयर का एक प्रमुख घटक अगले साल फिर से लिखा जा रहा है - एक ग्राफिक इंटरफ़ेस के साथ! Ooooooh-aaaaaaah! मैं ऑल-ट्विटर हूं ... (<pheh!>)

— बॉब जार्विस

Answer 4

परियोजना प्रबंधन के लिए कोई समर्पित संसाधन नहीं

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

नए प्रोग्रामर के लिए खराब उपकरण

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

Comments

+1। अपने कर्मचारियों के लिए अच्छे उपकरण उपलब्ध नहीं कराना "सभी के लिए लिखित" विफल होने के लिए बाध्य है।

— टेरेंस पोंस

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

— Fil

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

— बॉब मर्फी 20

Kaz: हर डेवलपर के पास एक पर्याप्त मशीन होनी चाहिए। यदि नया हार्डवेयर खरीदने का अर्थ है कि नए डेवलपर का पीसी अन्य डेवलपर्स की तुलना में थोड़ा बेहतर है, तो ठीक है, सबसे खराब स्थिति में आपके पास स्वैप मशीन हैं यदि वे डिक-आकार-प्रकार के लोग हैं। सामान्य लोग बस तब तक देखभाल नहीं करेंगे जब तक उनके पास वह समीकरण है जो उन्हें कुशलता से काम करने देता है। वर्तमान में मैं जिस स्थान पर काम कर रहा हूं, उस व्यक्ति की तुलना में मुझे एक नया (शायद तेज) पीसी मिला है, जिसने मुझे काम पर रखा है। मेरे बाद आए लोग भी नए हैं, शायद तेज, पीसी। अंदाज़ा लगाओ? किसी को परवाह नहीं है, क्योंकि हमारी सभी मशीनें काफी तेज हैं।

— user281377

जब हार्डवेयर अपर्याप्त होता है, तो मैं प्रबंधन को यह बताने के लिए एक बिंदु बनाता हूं, आमतौर पर लंबे समय के संकलन के दौरान मेरे toenails को क्लिप करने या पेपर पढ़ने जैसे उपयोगी काम करके। मुझे पुरानी धीमी मशीन मिलती है? ज़रूर, कोई संभावना नहीं। ओह, तुम एक भीड़ बग ठीक हो गया है और मैं निर्माण करने के लिए मिल गया है? ज़रूर बात, मिस्टर-मैनेजर-बवाना-साहिब-यार - 90 मिनट में फिर मिलेंगे! (एक बार एक प्रबंधक ने मुझसे पूछा कि मैंने पूरे दिन क्या किया - मैंने उससे कहा "चार बार पुन: ऐप बनाया।" 10 घंटे लग गए। "नई मशीन ने लंबे समय बाद नहीं दिखाया ... :-)

— बॉब जार्विस

Answer 5

हम प्रोग्रामर को टेस्टर / तकनीकी लेखकों के रूप में दोगुना करके पैसे बचा सकते हैं

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

BTW: डेवलपर्स हमेशा एक तंग समय सीमा के खिलाफ हैं।

Comments

चतुर लोग कुछ भी अच्छी तरह से कर सकते हैं।

— जॉन हॉपकिंस

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

— डेविड थॉर्नले

मेरा तर्क है कि यह प्रोग्रामर का काम है कि वे अपने कोड का परीक्षण करें, लेकिन मुझे यकीन नहीं है कि यदि आप इसका उल्लेख कर रहे हैं।

— बेन लेक

प्रोग्रामर को अपने स्वयं के कोड का परीक्षण करना चाहिए, न कि समर्पित परीक्षकों के बहिष्कार के लिए जो सॉफ्टवेयर को तोड़ने वाले पेशेवर हैं।

— JohnFx

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

— एडम ब्रुक

Answer 6

उत्पाद विकास से संबंधित अनुसंधान / पढ़ना / लिखना कोड संसाधन की बर्बादी है।

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

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

Comments

काश मैं इसे एक से अधिक बार उखाड़ सकता।

— MAK

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

— टिम विलिसक्रॉफ्ट

Answer 7

कई मामलों में ऑफशोरिंग में अधिक पैसा खर्च होता है। मेरी कंपनी में नए कर्मचारी स्लॉट प्राप्त करना बहुत कठिन है, हमें आउटसोर्स करने के लिए भारी धक्का दिया जाता है। यह भी साइट पर ठेकेदारों को पाने के लिए कठिन है; वहाँ 3 का अनुपात है: 1 अपतटीय के लिए तट पर वे बनाए रखने के लिए माना जाता है। नतीजतन, कई टीमें सिर्फ एक दर्जन अपतटीय काम पर रखती हैं और बमुश्किल उनका उपयोग करती हैं, बस इसलिए उन्हें 4 ऑनसाइट ठेकेदार मिल सकते हैं।

Comments

+1। ऑफ-शोरिंग के साथ मेरा अनुभव यह है कि यह अनिवार्य रूप से एक अच्छे सौदे की तुलना में अधिक पैसे खर्च करता है।

— एडम क्रॉसलैंड

+1, लेकिन यदि सही तरीके से उपयोग किया जाए तो अपतटीय काम कर सकते हैं

+1। हमें लगता है कि प्रत्येक नए प्रोजेक्ट पर अलग-अलग ऑफ-डिवेलप डेवलपर्स मिल रहे हैं, जिसका अर्थ है कि ऑन-शोर डेवलपर्स अपना अधिकांश समय नए ऑफ-एज देवों को तकनीकी सहायता प्रदान करने के अलावा व्यवसाय और तकनीकी डोमेन मॉडल को पढ़ाने में बिताते हैं। परियोजना का अंत और वे कहीं और चले गए हैं और हम 'सस्ते' डेवलपर्स के अगले सेट के साथ फिर से शुरू करते हैं।

— क्रिस नाइट

कई टीमें सिर्फ एक दर्जन अपतटीय किराए पर लेती हैं और बमुश्किल उनका उपयोग करती हैं, बस इसलिए उन्हें 4 ऑनसाइट ठेकेदार मिल सकते हैं। वाह।

— पूलि

और यह भूल जाते हैं कि यह बहुत स्वाभाविक रूप से समय सीमा का विस्तार करेगा। हमारे पास अपतटीय QA है और किसी चीज को फिर से शुरू करने के लिए 3-4 दिन लग सकते हैं, एक ही कार्यालय में जुड़वा लोग समय के अंतर के कारण एक घंटे के भीतर फिर से शुरू कर सकते हैं।

— HLGEM

Answer 8

लंबी प्रतिक्रिया लूप्स!

यह हर किसी के लिए होता है: आप कुछ ऐसा बनाते हैं जो आपको लगता है कि भयानक है, और यह पता चलता है कि आप गलत थे। यह समस्या नहीं है। समस्या यह है कि आप कितनी देर तक इमारत बनाने से पहले यह पता लगा लेते हैं कि आपको रुकना चाहिए।

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

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

एक बार जब आप लघु प्रतिक्रिया छोरों के महत्व को देखना शुरू करते हैं, तो आप इसे हर जगह देखेंगे। जैसे, Ooda लूप की सैन्य धारणा ।

Comments

+1। इसके अलावा: प्रतिक्रिया लूप जितना लंबा होगा, आपको कार्य के बारे में उतना ही कम याद रहेगा। चरम पर, आपको फिर से पूरे कोडबेस के साथ खुद को फिर से परिचित करना होगा।

— जोसेफ ताननबौम

कैसे एक झूठी अर्थव्यवस्था है? इच्छित बचत क्या है?

— क्रिस पिटमैन

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

— विलियम पिएत्री

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

— जोनाथन नेफेल्ड

Answer 9

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

बहुत झूठी अर्थव्यवस्था की परिभाषा।

Comments

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

— जॉन हॉपकिंस

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

— JBRWilkinson

-1, 20 मिनट की पैदल दूरी आपके दिमाग को मुक्त करने और समस्या पर एक नया दृष्टिकोण प्राप्त करने के लिए एकदम सही है।

— मालफिस्ट

@ मालफिस्ट: जैसा कि मैंने समझा, यह सिर्फ 20 मिनट की पैदल दूरी पर नहीं था, बल्कि 15 मिनट तक इंतजार करने से वास्तव में कॉफी का काम भी बाधित हो गया। दिन में किसी भी समय 45 मिनट का ब्रेक बहुत अच्छी तरह से एक और डेढ़ घंटे के लिए उत्पादकता को नष्ट करने वाला है। सभी को कॉफी पर महीने में 100 रुपये की बचत होती है।

— एरिकबॉर्स्मा

२० + १५ = ३५ [छह और चरित्र]

— मालफिस्ट

Answer 10

सिंगल-स्क्रीन वर्कस्टेशन प्रदान करना क्योंकि एक दूसरा मॉनिटर बहुत महंगा है । यहां तक ​​कि अगर यह आपको हर साल केवल एक घंटे काम करता है, तो भी एक दूसरी स्क्रीन एक अच्छा निवेश है। मुझे पता है कि खदान ने मुझे कई, कई घंटों के काम से बचाया है।

एक मल्टी-मॉनिटर सेटअप विकास कार्यों को ही नहीं, लगभग किसी भी कार्य को अधिक कुशल बना सकता है। तीन मॉनिटर दो से भी बेहतर है, लेकिन प्रभाव हर अतिरिक्त स्क्रीन के साथ कम स्पष्ट हो जाता है।

बहु-मॉनिटर सेटअप:

• ओवरहेड स्विचिंग विंडो में कमी
• आपको पृष्ठभूमि (मेल, संकलन, आदि) में चल रहे सामान पर नज़र रखने की अनुमति देता है।
• आप स्वतंत्रता की भावना दे। यह एक आलिंद बनाम झाड़ू कोठरी में होने जैसा है।
• आदि...

Comments

एक बार उस मुद्दे का सामना कर रहा था। हमारे सीईओ में से एक को एक मेल लिखा है कि यह गणना करते हुए कि दक्षता में 5% की वृद्धि हुई है, मैंने अपनी शुद्ध आय के सापेक्ष लगभग आधे महीने में निगरानी के लायक राशि बचाई होगी। यह गणना बहुत अधिक विडंबना थी ... लेकिन ... मुझे लगता है कि आप पहले से ही कहानी का अंत जानते हैं :)

— राफेल

Answer 11

एक सलाहकार को सस्ता हार्डवेयर दिया जाता है जब सलाहकार की लागत $ 150 / घंटा से अधिक होती है ।

इसे एक बेहतर हार्डवेयर के परिप्रेक्ष्य में रखना कम से कम काम को 30min प्रति दिन अधिक प्रभावी बना सकता है। यह प्रति माह 30 मिनट * 20 दिन का काम = 600min / महीना = 10 घंटे / महीना> और अधिक कि 1 दिन की नौकरी = 10 घंटे * 150 $ / घंटा = 1500 $

अब एक सलाहकार काम नहीं करेगा यदि वह 1500 डॉलर का कंप्यूटर रखता है? क्या यह सलाहकार को कम परेशान करेगा?

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

Comments

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

— बॉब मर्फी

कोई अपराध नहीं है, लेकिन अगर मैं एक सलाहकार के लिए $ 150 / hr का भुगतान कर रहा हूं, तो उसके पास बेहतर कंप्यूटर होगा।

— स्टीवन एवर्स

@SnOrfus: यह आमतौर पर कॉर्पोरेट वातावरण में काम नहीं करता है, जहां डोमेन पर अनुमत पीसी के सख्त नियंत्रण होते हैं। आपको उन्हें हार्डवेयर प्रदान करना होगा।

— हार्डकोड

@ हर्डकोड - हाँ, मुझे लगता है। मैं अब बिंदु देख सकता हूं।

— स्टीवन एवर्स

@HardCode हाल ही में एक परियोजना पर, हमें (ठेकेदारों) को उनके आंतरिक कॉर्पोरेट नेटवर्क में जोड़ने के बजाय, उन्होंने हमें हमारी नई डीएसएल लाइन से अलग कर दिया। 3 डेवलपर्स @ $ 40 प्रति माह के लिए एक समर्पित डीएसएल लाइन चंप परिवर्तन है और आईटी कर्मचारियों को घबराहट में भेजे बिना अपडेट को दूरस्थ रूप से धकेलना आसान बनाता है। साथ ही, यदि उत्पादन कोड हमारे कोड को चलाने वाला संक्रमित हो जाता है और दुर्घटनाग्रस्त हो जाता है, तो यह हमारी गलती है क्योंकि हम अपने संचार और व्यक्तिगत लैपटॉप की सुरक्षा के लिए जिम्मेदार हैं। क्या आप जीत-जीत कह सकते हैं।

— इवान प्लाइस

Answer 12

काम के महीने नियोजन के दिनों को बचाते हैं

(योजना में पर्याप्त समय निवेश नहीं)

Comments

ग्रेड स्कूल में एक कहावत थी कि लैब में कुछ सप्ताह आपको लाइब्रेरी के एक घंटे का समय बचा सकते हैं।

— डेविड थॉर्नले

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

— बॉब मर्फी

यदि आप योजना बनाने में विफल रहते हैं, तो आप असफल होने की योजना बनाते हैं

Answer 13

अधिकांश प्रचलित मुझे संदेह है कि प्रबंधकों को डेवलपर्स को उन उपकरणों के साथ प्रदान नहीं किया जाता है जो उन्हें अपना काम कुशलता से करने की आवश्यकता होती है।

मूल रूप से, जोएल टेस्ट पर अंक 9 ।

Comments

मैं उन परियोजनाओं पर गया हूँ जहाँ वे हमें खरीदने के बजाय एक या दो सप्ताह बर्बाद करते हैं, उदाहरण के लिए, पहले से किए गए काम के साथ $ 300 के लिए एक पुस्तकालय - और बेहतर (मैं "डेवलपर्स को नियंत्रित नहीं करता हूं" जहां मैं काम करता हूं।) या कुछ सॉफ्टवेयर टूल चुनें "क्योंकि यह" यह या उस "कंपनी" द्वारा बनाया गया है यह देखने के बजाय कि क्या बेहतर विकल्प हैं, तो हमारे जीवन को सालों तक नरक बना दें।

— मेटल मिक्स्टर 12

मैं उस एक में चला गया हूँ। PM / ग्राहक तर्क था कि हमारे पास ग्राहक के लिए चीजें खरीदने के लिए बजट आइटम नहीं था (संपर्क परिवर्तन एक कुतिया थे) इसलिए हमें पहिया (फिर से) को फिर से बनाना होगा।

— केन हेंडरसन

Answer 14

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

Comments

+1। हे भगवान हाँ। यह वर्तमान में एक प्रमुख परियोजना पर एक महाकाव्य पैमाने पर हो रहा है जहां मैं काम करता हूं।

— बॉबी टेबल्स

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

— बॉब जार्विस

मैंने इस बारे में एक बार एक महान उद्धरण सुना: 9 महिलाएं एक महीने में एक बच्चा नहीं बना सकती हैं

— रिचर्ड

@ रिचर्ड ने मुझे एक बैठक में इस्तेमाल किया। मुझे अपार खुशी दी!

— तजार्ट

Answer 15

हर दिन बैठकें :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  

Comments

मिलने के लिए बस मिलना ...

— गण

आज के लिए एजेंडा: कल की बैठक के एजेंडे में क्या होगा?

— मार्क सी

यदि ये छोटी हैं तो दैनिक बैठक ठीक है ; स्क्रम-शैली की 3-मिनट की स्टैंड-अप मीटिंग्स बहुत समय बर्बाद नहीं करती हैं, लेकिन हर किसी को बाकी सभी के विकास के बारे में जागरूक रखती हैं। कई विमुख प्रतिभागियों के साथ लंबी बैठकें विषाक्त होती हैं, हालांकि।

— 9000

@ मर्क सी - यह एक मजाक की तरह लग सकता है, लेकिन मुझे वास्तव में बैठकों के लिए आमंत्रित किया गया है ताकि योजना बनाई जा सके कि अगले दिन की बैठक का एजेंडा क्या होगा ...

— गेविन कोट्स

कोट्स @Gavin यह एक वास्तविक और स्थिति ... :) है

— Zzz

Answer 16

आंतरिक रूप से इसे विकसित करने के बजाय शेल्फ सॉफ़्टवेयर को खरीदना।

मुझे एचआर और बायोलॉजिकल लैबोरेट्रीज पर ध्यान केंद्रित करते हुए एन्ट्रेप स्केल स्केल मैनेजमेंट सिस्टम का अनुभव है।

शेल्फ समाधान के लिए £ 50-100k की लागत और व्यावसायिक आवश्यकताओं को पूरा करने के लिए आगे के विकास और अनुकूलन की आवश्यकता थी।

आंतरिक रूप से विकसित समाधान को विकसित करने के लिए (<6) महीने लगे, अन्य परियोजनाओं के साथ समानांतर में काम किया गया, और पहले से ही कार्यरत डेवलपर का उपयोग किया।

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

(समानांतर में अन्य परियोजनाओं पर काम कर रहे पहले से ही काम पर रखे गए डेवलपर के 6 महीने। तो ~ 10k। और इसमें बंद शेल्फ समाधान से जुड़ी समर्थन लागत शामिल नहीं है)। प्रमुख बिंदु यह है कि आंतरिक रूप से विकसित प्रणाली वास्तव में इस्तेमाल की जा रही थी! तो आपके पास इसके साथ जोड़ा गया लागत लाभ है, जिसकी मैं गणना नहीं कर सकता।

मैं बुनियादी वेबसाइटों आदि के लिए सहमत हूँ, क्यों अपने खुद के विकास को परेशान करते हैं। लेकिन किसी भी बड़ी जटिल प्रणाली के लिए और यदि आपके पास पहले से ही घर के कौशल हैं, तो मैं इसे स्वयं बनाऊंगा ।

Comments

मुझे यकीन है कि विपरीत के उदाहरणों का एक गुच्छा भी है।

— जॉन हॉपकिंस

खरीदने या विकसित करने के लिए उचित परिश्रम करने वाले सही लोगों के लिए नीचे आता है। इतना ही आसान। करने से पहले सोचो। (+1)

— देवसोलो

@ डेवोलो: ऑन स्पॉट। बिल्ड-एंड-बाय डिसिजन को कॉस्ट-बेनिफिट्स एनालिसिस द्वारा समर्थित किया जाना चाहिए, बजाय इसके कि एक इमोशन 'यहां आविष्कार नहीं हुआ' या 'मुझे XXX का सॉफ्टवेयर पसंद है' वाला रवैया है।

— JBRWilkinson

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

— 21

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

— इयान

Answer 17

ओपन सोर्स के विकल्प बेहतर और मुफ्त होने पर महंगे ऑफ-द-शेल्व उत्पादों को खरीदना।

Git का उपयोग कितनी कंपनियां करती हैं? कितनी कंपनियां कुछ भद्दे एंटरप्राइस वर्जन कंट्रोल का उपयोग करती हैं?

Comments

एर्म, क्या इसे "सबसे खराब झूठी अर्थव्यवस्था" माना जा सकता है? या शायद आपको अधिक विस्तृत करने की आवश्यकता है ...?

— गण

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

— पीटरएलेनवेब

@Gan: उन्हें लगता है कि खुले स्रोत का उपयोग करना झूठी अर्थव्यवस्था है, लेकिन उनके पास यह सब पीछे की ओर है।

— hasen

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

— बॉब मर्फी

ओपन सोर्स बनाम वाणिज्यिक उत्पाद मेरे अनुभव में वास्तव में "केस बाय केस" आधार है।

— मेटलमीस्टर

Answer 18

बहुत सरलता के बिना "सरल" भाषाओं का उपयोग करना

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

Comments

@burnt_hand: मैं मूल रूप से भाषा की पसंद के संदर्भ में प्रबंधन के अत्यधिक जोखिम से बचने की बात कर रहा हूं।

— dsimcha

+1: बस C का उपयोग करते रहें क्योंकि "हमारे पास वे कौशल हैं और कुछ नई-फैंसी भाषा सीख रहे हैं जैसे कि Python / Perl / PHP बहुत जोखिम में जोड़ता है"। इसे एक से अधिक बार सुना। क्या इसका मतलब यह है कि टीम एक नई भाषा सीखने के लिए बहुत बेवकूफ है?

— एस.लॉट नोव

@ एस.लॉट रिक्रूटमेंट एजेंट सोचते हैं कि आप हैं!, लेकिन यह एक और कहानी है

— burnt_hand

ऐसी कंपनियाँ जो जावा और C # से चिपकी रहती हैं और अजगर या रूबी को छूने से डरती हैं क्योंकि वे "उद्योग मानक" नहीं हैं, जो मुझे याद दिलाती हैं: paulgraham.com/avg.html

— hasen

@hansen: पॉल ग्राहम निबंध आंशिक रूप से मुझे इस पोस्ट को लिखने के लिए प्रेरित करता है। मेरी अन्य प्रेरणा डी प्रोग्रामिंग भाषा के लिए मेरा काम विकासशील पुस्तकालय (मानक पुस्तकालय सहित) था।

— dsimcha

Answer 19

खराब प्रोजेक्ट मैनेजर / टीम लीड।

चूंकि एक अक्षम व्यक्ति में लोगों के समूह के काम को बर्बाद करने की शक्ति होती है। अंत में, परियोजना ऊपरी प्रबंधन (परियोजना / टीम लीड) के निर्णयों के बिना बहुत बेहतर करेगी।

"बस इसे जल्दी करो, हम बाद में रिफ्लेक्टर करेंगे"।

Comments

मैं मानता हूं कि खराब प्रबंधक हैं, लेकिन "ऊपरी प्रबंधन के फैसले के बिना परियोजना बेहतर होगी"? आम तौर पर ये ऐसे लोग हैं जो परियोजना को प्रायोजित कर रहे हैं। यह मुझे थोड़ा सा लगता है जैसे डेवलपर्स से मैं मिला हूं जो सोचते हैं कि प्रौद्योगिकी को समझना व्यापार को समझने से ज्यादा महत्वपूर्ण है और यह भूल जाओ कि वास्तविक ग्राहक कौन है।

— जॉन हॉपकिंस

@ जौन हॉपकिंस ऊपरी प्रबंधन के साथ मैं ग्राहक का संदर्भ नहीं देता। मुद्दा "खराब प्रोजेक्ट मैनेजर" हैं जो गलतियों के बाद गलतियाँ करते हैं, और लोगों के समूह के खिलाफ जाते हैं। आप कौन सोचते हैं कि "बस जल्दी करो, हम बाद में मना करेंगे"। उच्चतम दर के साथ उत्तर पढ़ें!

— आमिर रज़ाई

आह, स्पष्ट। मैं अपने -1 को हटा देता हूं।

— जॉन हॉपकिंस

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

— बर्नार्ड दई

@ बर्नार्ड - समय और लागत औसत दर्जे का है। गुणवत्ता? इतना नहीं। दुख की बात है लेकिन IMO सच है ...

— बॉब जार्विस

Answer 20

उपयोगकर्ता की आवश्यकताओं को याद कर रहा है

एक सॉफ्टवेयर उत्पाद डिजाइन करने का एक महत्वपूर्ण और कठिन कदम यह निर्धारित करता है कि ग्राहक वास्तव में क्या करना चाहता है।

मानो या न मानो कभी-कभी यह हिस्सा गायब है या पुराना है। यह लागत की बात आती है कि एक कार्यात्मकता पैदा करता है जो अंतिम उपयोगकर्ता ने कभी नहीं मांगा।

Comments

मुझे लगता है कि यह सबसे ऊपर होना चाहिए!

— रूपेश शेनॉय

Answer 21

उत्पादकता रचनात्मकता से अधिक मूल्य की है

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

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

Answer 22

नीचे सभी खराब हो सकते हैं जब उपयोग किया जाता है या अनुचित तरीके से उपयोग नहीं किया जाता है

• बाहरी बनाम इनडोर सॉफ्टवेयर

• आईएसओ 9001 अनुपालन (अर्थव्यवस्था - उत्पाद की गुणवत्ता में कमी होने पर एक एमएसएस हानि जोखिम का शमन)

• विकास / क्यूए आउटसोर्सिंग

• विकास / निर्माण / रिलीज / समर्थन प्रक्रियाओं

Comments

आईएसओ 9001 (झूठी) "अर्थव्यवस्था" कैसे है?

— एंड्रयू ग्रिम

@Andrew ग्रिम - अनुपालन कुछ गुणवत्ता स्तर सुनिश्चित करता है जो खराब गुणवत्ता (उदाहरण के लिए MSS हानि) के परिणामस्वरूप होने वाले जोखिमों को कम करता है, इसलिए संभावित अर्थव्यवस्था स्पष्ट है। छोटे विभागों के लिए यह अनुचित हो सकता है क्योंकि ओवरहेड पर नुकसान अधिक होता है, फिर संभावित जोखिम से

— ग्रस्त

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

— जॉन हॉपकिंस

@ एंड्रयू ग्रिम - "केवल" चीज जो आईएसओ 9001 की गारंटी के अनुरूप है, दोहराए जाने योग्य गुणवत्ता है। यह "उच्च" गुणवत्ता की गारंटी नहीं देता है। हालाँकि, यदि कंपनी जिस स्पेस में रहना चाहती है, उसके लिए ISO 9001 की योग्यता आवश्यक है, तो यह आवश्यक है।

— वेटिन

@Vatine: आईएसओ 9001 की गारंटी, सुसंगत, दोहराने योग्य प्रक्रिया है। कुछ क्षेत्रों में, जहां सुसंगत प्रक्रियाएं लगातार गुणवत्ता प्रदान करती हैं, यह महत्वपूर्ण है। यह उच्च गुणवत्ता की गारंटी नहीं देता है, लेकिन यदि कोई ग्राहक आपके द्वारा किए गए कुछ को देखता है और जानता है कि आप आईएसओ 9001-प्रमाणित हैं, तो वे समान गुणवत्ता के बारे में आश्वस्त होंगे।

— डेविड थॉर्नले

Answer 23

बहुत से गैर-बिल योग्य वितरण प्रबंधक वाले।

कुछ साल पहले, हमारी कंपनी में हमारे पास कई बड़े बजट की परियोजनाएं चल रही थीं और भर्ती चरम पर थी। उस समय हमारी कंपनी ने बहुत से डिलीवरी मैनेजरों को काम पर रखा था (उनमें से कई गैर आईटी थे!) और बहुत कम कोडर / परीक्षक। प्रोग्रामर अनुपात के प्रबंधक का शाब्दिक अर्थ 1: 2 था। बाद में, उन परियोजनाओं के पूरा होने के बाद, हमारे पास एक ऐसी स्थिति थी जहां हमारे पास इनमें से कई प्रबंधक थे (उनमें से कुछ असली सुस्त थे) बेंच पर बैठकर कुछ भी नहीं कर रहे थे। हमारे पास एक मूल्यांकन चक्र था, जहां सभी को बहुत कम / कोई वृद्धि नहीं मिली (यहां तक ​​कि हमारे मेहनती प्रोग्रामर, आह) ताकि कंपनी को किसी को बंद करने की ज़रूरत न पड़े! सौभाग्य से, कंपनी ने इस स्थिति को महसूस किया और इस साल पहली तिमाही में राइट्स किया!

Answer 24

रूपरेखा (उर्फ समयपूर्व अनुकूलन) से पहले अनुकूलन।

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

जैसे, यह एक बहुत ही झूठी अर्थव्यवस्था है, और इस तरह की झूठी अर्थव्यवस्था जो कभी-कभी अनुभवी पेशेवरों को भी उलझा देती है।

Answer 25

सीमित या कोई इंटरनेट का उपयोग नहीं

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

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

Answer 26

अपने डेवलपर्स को 15 इंच का मॉनिटर और लो स्पेक पीसी का उपयोग करना चाहिए क्योंकि यह कॉर्पोरेट मानक है।

उचित आकार के मॉनिटर सस्ते होते हैं, इंस्टाल करने के लिए त्वरित और प्रोग्रामर को और अधिक उत्पादक बनाने के साथ-साथ आपके प्रोग्रामर सोचते हैं कि आप उनके बारे में परवाह करते हैं।

Answer 27

व्यवसाय प्रशासन के बहुत से स्नातक (या जैसे), पदानुक्रमित रूप से आयोजित, जो कि वे सोचते हैं कि आधुनिक प्रबंधन के बारे में क्या लागू करने का प्रयास करें: "KPI", "SLA" वाले लोगों को परेशान करना और क्या नहीं, "रिपोर्ट" की आवश्यकता के बिना (बिना) बेशक, उन्हें उत्पन्न करने के लिए बुनियादी ढांचे की देखभाल करना), ताकि प्रोग्रामर अपने दिनों को फैंसी EXCEL शीट्स, Q4 रिपोर्ट में भरने में बर्बाद कर दें और क्या न करें और एक महान नए प्रबंधन उपकरण से कॉपी करें और दूसरे में पेस्ट करें (यह नियम लगता है कि ये उपकरण कभी भी एक-दूसरे के साथ अप्रभावित या एकीकृत नहीं होते हैं), और उन बैठकों में भाग लेते हैं जहां रिपोर्ट और आंकड़े प्रस्तुत किए जाते हैं (और हर कोई इस या उस KPI को पूरा करने में विफल होने के बारे में दोषी महसूस करता है)।