मिथक मैन महीने का कितना हिस्सा लागू होता है?

Question

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

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

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

Answer 1

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

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

Answer 2

आज भी यह सच है जितना दिन लिखा गया था। ऐसा इसलिए है क्योंकि यह मूल रूप से एक ही परियोजना पर काम करने वाले लोगों के बीच संचार के बारे में है, और पिछले 30 वर्षों की प्रगति में से कोई भी इसमें काफी बदलाव नहीं आया है।

बेशक, हमने उन 30 वर्षों में बहुत कुछ सीखा है, लेकिन हमारे उपकरण और उपक्रम में सभी सुधार बढ़ते जा रहे हैं, ब्रूक्स के "चांदी की बुलेट" भविष्यवाणी के अनुसार।

Answer 3

जो मेरे दिमाग में चिपकते हैं: "संस्करण 2" अभी भी लागू होता है और इसलिए "अधिक लोगों को जरूरी तेज़ी से जोड़ना" नहीं होता है।

स्पॉल्स्की अपने तरीके से "संस्करण 2" पर चर्चा करता है। मुझे याद नहीं है कि क्या वह विशेष रूप से एमएमएम से जुड़ा है लेकिन यह अवधारणा में बहुत समान है।

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

किसी ने कहा कि कंप्यूटर विज्ञान में सब कुछ 1 9 60 में खोजा गया था और तब से सब कुछ व्युत्पन्न हो गया है।

Answer 4

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

Answer 5

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

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

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

Answer 6

इस प्रकार की तरह यह पूछने की तरह नहीं है कि क्या सूर्य त्ज़ू का युद्ध युद्ध अभी भी युद्ध के लिए लागू है क्योंकि हमारे पास आधुनिक उपकरण हैं?

Answer 7

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

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

Answer 8

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

Answer 9

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

Answer 10

मैं इसे किसी भी व्यक्ति के लिए "पढ़ना" किताबों में से एक माना जाता हूं जो सॉफ्टवेयर विकास प्रक्रिया को समझना चाहता है।

Answer 11

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

Answer 12

प्रसिद्ध ब्रूक्स लेखन, "नो सिल्वर बुलेट" और "द मिथिकल मैन-महीने" दोनों क्रमशः प्रोग्रामिंग भाषाओं और परियोजना प्रबंधन में मौलिक सीमाओं के स्पष्टीकरण हैं।

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

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

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

व्यक्तिगत रूप से, मैं सिर्फ "द जॉय ऑफ द क्राफ्ट" अनुभाग के लिए पुस्तक पढ़ूंगा। मैंने कभी भी कुछ भी नहीं पढ़ा है जो इतनी सुंदरता से वर्णन करता है कि प्रोग्रामिंग के सर्वोत्तम पर जैसा लगता है। (यदि आप उत्सुक हैं, तो यह पृष्ठ 7 पर है, और amazon.com "लुक इनसाइड!" सुविधा में देखने योग्य)

Answer 13

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

Answer 14

सामाजिक कारक अभी भी मौजूद हैं, क्योंकि मनुष्य अभी भी अनिवार्य रूप से वही जानवर हैं जो हम 50 साल पहले थे।

तकनीकी उदाहरण लगभग पूरी तरह से अप्रचलित हैं, और जब आप 0.034 एमआईपीएस सिस्टम/360 के बारे में सोचते हैं तो केवल समझ में आता है। जब आपको केवल 8 केबी मेमोरी मिलती है, तो यह सुझाव देते हुए कि उपयोगकर्ता को छलांग लगाने के लिए जिम्मेदार होना चाहिए साल, सिस्टम मेमोरी के 26 बाइट्स बर्बाद करने के बजाय (ब्रूक्स के रूप में) समझ में आया, लेकिन आज यह मूर्खतापूर्ण लगता है। मुझे आज कोई भी प्रणाली नहीं पता है - आपका टेलीफोन सबसे शक्तिशाली ओएस/360 सिस्टम की तुलना में हजारों गुना अधिक शक्तिशाली है। आज हम उपयोगिता और मानव-कंप्यूटर परस्पर संपर्क के बारे में बहुत कुछ जानते हैं, और इस श्रेणी की चीज़ के लिए उपयोगकर्ता को जिम्मेदार बनाना सिर्फ पागल है।

Answer 15

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

शेड्यूलिंग (उच्चारण शेड-उलिंग), योजना और सभ्य प्रबंधन के लिए कोई विकल्प नहीं है।

इनमें से अधिकतर "एक लाइनर" या "सुनहरे नियम" के साथ, पत्थर में सेट की तुलना में उन्हें अधिक दिशानिर्देश (संदर्भ के साथ) पर विचार करें।