सॉफ्टवेअर वर्ल्डचे हास्यास्पद कायदे

सॉफ्टवेअर डेव्हलपर्स सारख्या स्मार्ट लोक इतक्या वेळा ते का ओरडतात याचा तुम्हाला कधी विचार आला आहे? असे लोक आहेत ज्यांनी केले. या पोस्टमध्ये आम्ही पुनरावलोकन करतो व्यावसायिकांच्या वर्तनाचे वर्णन करणारे काही अलिखित कानून संगणकीय

माझा पहिला संगणक एक कमोडोर 64 होता. जवळजवळ 30 केबी रॅम सिस्टमसाठी होता, वर्ड प्रोसेसिंग, गेमिंग, फॅमिली बिझिनेस अकाउंटिंग, आणि माझ्या मालकीच्या 32 जीबी संगणकासह मी जे काही करतो त्याबद्दल 6 केबी सोडली. यामुळे प्रश्न मुक्त होतो आजची उपकरणे सॉफ्टवेअरच्या गरजांना प्रतिसाद देतात की सॉफ्टवेअर उपलब्ध असल्याने अधिक हार्डवेअर संसाधने वापरतात?

प्रामाणिकपणाने, खेळ एकसारखे नसतात, ग्राफिक्स समान गुणवत्ता नसतात आणि चित्रपट पाहणे आणि संगीत ऐकणे अशक्य झाले असते. तथापि, एक मदत करू शकत नाही परंतु असा विचार करू शकतो असे काही कार्यक्रम आहेत जे खरोखरच नवीन काहीही योगदान न देता आवृत्त्या सोडतात आणि अधिकाधिक संसाधने वापरतात.

येथे कारणे आहेत.

झाविन्स्कीचा कायदा

नेटस्केप विकसक जेमी झॉविन्स्की यांनी असा युक्तिवाद केला प्रत्येक प्रोग्राममध्ये ईमेल वाचण्यात सक्षम होईपर्यंत वैशिष्ट्यांचा समावेश असतो. जर तो यशस्वी झाला नाही तर त्याची जागा दुसर्‍याने घेतली आहे जो असे करण्यास सक्षम आहे.

जेव्हा ते म्हणाले तेव्हा विनोद असा होता की तो प्रोग्रामचा संदर्भ घेत होता ज्यांचा मूळ हेतू ईमेल क्लायंटचा नव्हता. जेव्हा गूगल प्ले वर बर्‍याच अ‍ॅप्सनी त्यांचे कार्य करण्याची गरज नसते अशा फोन घटक आणि वापरकर्ता डेटामध्ये प्रवेश करण्याची परवानगी मागितली तेव्हा हे मजेदार होणे थांबले.

वापरकर्त्यांनी हेरगिरी करण्याचा प्रयत्न केल्याचा भाग म्हणून काहींनी याचा अर्थ लावला. परंतु हे करणे शक्य आहे म्हणूनच काहीतरी करणे कदाचित मानवी स्वभावाचे आहे.

पीटरचे तत्व सॉफ्टवेअरवर लागू झाले

लॉरेन्स पीटर असे म्हणते की प्रसिध्द झाले की श्रेणीरचना मध्ये एखादी व्यक्ती अशा स्थितीत काम करते ज्यासाठी तो अत्यंत अक्षम आहे. परंतु त्यांच्याकडे जटिल प्रकल्पांबद्दल काहीतरी बोलण्याची वेळही होती:

"एक जटिल प्रकल्प अगदी त्याच्या स्वत: च्या विकसकांकडून समजून घेण्याइतपत जटिल होईल."

किमान आश्चर्यचकित करण्याचे तत्व

१ 1984 in in मध्ये आयबीएम सिस्टम जर्नलमध्ये प्रकाशित केलेले हे तत्व असे नमूद करते:

"आवश्यक वैशिष्ट्यामुळे मोठे आश्चर्य घडल्यास त्या वैशिष्ट्यास पुन्हा डिझाइन करण्याची आवश्यकता असू शकते."

दुसऱ्या शब्दांत, जर एखादा भाग किंवा सर्व सॉफ्टवेअर वापरकर्त्यांकडे वापरले जाण्यापेक्षा खूपच वेगळे असेल तर सर्वोत्कृष्ट म्हणजे एक नवीन डिझाइन. तद्वतच, साध्य करण्यासाठी प्रयत्न करा वाढीव सुधारणा जे प्रभावी होण्यासाठी पुरेसे मोठे आहेत परंतु परिचित राहण्यासाठी इतके लहान आहेत वापरकर्त्यासाठी.

खूप वाईट शटलवर्थने जेव्हा युनिटी सुरू केली तेव्हा हे ध्यानात घेतले नाही.

सायबरनेटिक एंटोमोलॉजी कायदा

संगणक इतिहासातील पहिला बग खरा होता. मार्क II संगणकावरील एक रिले मध्ये पतंग उडला ज्यामुळे खराबी निर्माण झाली.

रूपकासह पुढे जाणे, सायबरनेटिक एंटोमोलॉजीच्या कायद्यानुसार आहे तेथे आणखी एक बग नेहमीच असेल.

हे सर्व संगणक वापरकर्त्यांस ठाऊक आहे. ऑपरेटिंग सिस्टमची किती चाचणी केली गेली हे महत्त्वाचे नसते, उशीर झाल्यावर नेहमीच एक त्रुटी आढळली.

केर्निघान कायदा

Linux Adictos आम्ही लेखक शोध इंजिन अनुकूल पद्धतीने लिहितो याची खात्री करण्यासाठी प्लगइन स्थापित केले आहे. पहिल्या दिवसापासून मला त्याचा तिरस्कार वाटत होता. थोडासा साहित्यिक उड्डाण घेऊन लिहिण्याचा कोणताही प्रयत्न ताबडतोब लाल वर्तुळाने निषेध केला जातो. जसजसा वेळ गेला तसतशी मला त्याची सवय झाली आणि मला क्वचितच टच-अप करावे लागतात.

प्रोग्रामरवरही हेच घडते, बर्‍याच वेळा ते समजून घेण्यास आणि देखरेख करण्यास सोप्या कोड्यापेक्षा कोडची त्यांची क्षमता दर्शविण्यास अधिक रस घेतात.

म्हणून केर्निघानच्या कायद्यानुसार असे आहेः

डीबगिंग प्रथम ठिकाणी कोड लिहिण्यापेक्षा दुप्पट कठीण आहे. म्हणून जर आपण कोड शक्य तितक्या हुशारीने लिहित असाल तर आपण परिभाषानुसार डीबग करण्यासाठी पुरेसे हुशार नाही. '

१ 90 / ०. चा नियम

वास्तविक आयुष्यात ज्याला नफ्यासाठी प्रकल्प सुरू केला असेल त्याला माहित आहे की प्रत्येक प्रकल्प अपेक्षित नफा मिळवण्यासाठी अर्धा अपेक्षित नफा मिळवण्यासाठी दुपटीने आणि बजेटपेक्षा दुप्पट खर्च करणार आहे.

संगणक जगात या कायद्याचे प्रकार आहेत. उदाहरणार्थ, एक टॉम कारगिल म्हणाला:

“कोडचा पहिला percent ० टक्के विकास वेळेचा पहिला the ० टक्के भाग दर्शवितो. उर्वरित 90 टक्के कोड विकास 90 टक्के इतर वेळ दर्शवितो.

हे स्पष्ट नव्हते का? कदाचित हॉफस्टॅडरचा कायदा मदत करेल:

"हॉफस्टॅडटरचा कायदा ध्यानात घेतल्याशिवाय, आपल्या अपेक्षेपेक्षा जास्त वेळ लागतो."

मला वाटते उबंटू आणि फेडोरा विकासकांना माहित असलेच पाहिजे. किंवा प्रत्येक 6 महिन्यांनी किमान ते लक्षात ठेवा.

ब्रूकचा कायदा

मुक्त स्त्रोत सॉफ्टवेअर प्रकल्पांमध्ये बर्‍याचदा दोन समस्या असतात; अर्थसहाय्य आणि सहयोगींचा अभाव. जोपर्यंत दुसरा समस्या नाही तोपर्यंत. ब्रूकच्या मते:

"वेळापत्रकात असलेल्या सॉफ्टवेअर प्रोजेक्टमध्ये कामगार जोडणे यास आणखी विलंब करेल."

समजावून सांगा, आपल्याला फक्त नवीन एन्कोडर अद्यतनित करण्याची आवश्यकता नाही. अधिक दस्तऐवजीकरण करावे लागेल, प्रत्येकास समक्रमित ठेवण्यासाठी अधिक नोकरशाही लागेल आणि कदाचित मारामारी होईल.

आणि अर्थातच आम्ही मित्र पार्किन्सन आणि त्याचा दावा विसरू शकत नाही आपण किती रिक्त जागा प्रारंभ कराल हे महत्त्वाचे नाही. आपल्याला नेहमीच अधिक आवश्यक असेल. तो ऑफिस स्पेसचा संदर्भ देत होता, परंतु रॅम आणि डिस्क स्पेससाठीही तेच होते.