सॉफ़्टवेयर इंजीनियरिंग के नियम

(lawsofsoftwareengineering.com)

126 पॉइंट द्वारा GN⁺ 10 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें

सॉफ़्टवेयर सिस्टम, टीमों और निर्णय-प्रक्रिया को प्रभावित करने वाले 56 सिद्धांतों और पैटर्नों का एक संकलन, जो टीम संचालन से लेकर आर्किटेक्चर, क्वालिटी, डिज़ाइन और निर्णय-निर्माण तक व्यापक दायरे को समेटता है
Conway का नियम, Brooks का नियम, Dunbar की संख्या जैसे टीम-संबंधी नियम दिखाते हैं कि संगठनात्मक संरचना सिस्टम डिज़ाइन और प्रोडक्टिविटी को सीधे प्रभावित करती है
आर्किटेक्चर क्षेत्र में Hyrum का नियम, CAP theorem, Gall का नियम आदि जटिल सिस्टम डिज़ाइन के दौरान ज़रूर ध्यान में रखे जाने वाले प्रतिबंधों और सिद्धांतों को व्यवस्थित करते हैं
क्वालिटी से जुड़े नियम technical debt, testing pyramid, Kernighan का नियम आदि के माध्यम से कोड क्वालिटी बनाए रखने और debugging की व्यावहारिक कठिनाइयों को संबोधित करते हैं
निर्णय-निर्माण के क्षेत्र में Dunning-Kruger effect, sunk cost fallacy, Pareto principle आदि विकास प्रक्रिया में आसानी से आ जाने वाले cognitive bias और निर्णय मानकों को समेटते हैं

टीम (Teams)

1. Conway का नियम (Conway's Law)

> संगठन वही सिस्टम डिज़ाइन करते हैं जो उनकी communication structure का प्रतिबिंब हो

सॉफ़्टवेयर आर्किटेक्चर का उस संगठन की संचार संरचना का स्वाभाविक रूप से अनुसरण करने की प्रवृत्ति
अगर टीम 3 भागों में बंटी है, तो सिस्टम भी 3 बड़े मॉड्यूल में बंटने की प्रवृत्ति रखता है
इसका उल्टा उपयोग करने वाली "Inverse Conway Maneuver" रणनीति भी मौजूद है: इच्छित आर्किटेक्चर के अनुसार पहले टीम संरचना को पुनर्गठित करने का दृष्टिकोण
माइक्रोसर्विस अपनाते समय टीम सीमाओं और service boundaries को एकसमान रखना प्रभावी होता है

2. Brooks का नियम (Brooks's Law)

> देर से चल रहे सॉफ़्टवेयर प्रोजेक्ट में लोगों को जोड़ने से वह और भी देर से पूरा होता है

नए लोगों के जुड़ने पर मौजूदा टीम सदस्यों को training और coordination में समय लगाना पड़ता है, जिससे कुल प्रोडक्टिविटी अस्थायी रूप से घटती है
टीम सदस्य बढ़ने पर communication paths ज्यामितीय रूप से बढ़ते हैं (n लोगों पर n(n-1)/2)
Frederick Brooks ने IBM OS/360 प्रोजेक्ट के अनुभव के आधार पर इसे 1975 की पुस्तक The Mythical Man-Month में स्थापित किया
Little का नियम(L = λ × W) से इसका मात्रात्मक स्पष्टीकरण संभव है: लोगों को बढ़ाने पर WIP बढ़ता है, लेकिन throughput स्थिर रहता है, जिससे lead time उल्टे बढ़ सकता है
समाधान लोगों को बढ़ाना नहीं, बल्कि scope बदलना या schedule समायोजित करना है

3. Dunbar की संख्या (Dunbar's Number)

> एक व्यक्ति लगभग 150 लोगों तक ही स्थिर संबंध संज्ञानात्मक रूप से बनाए रख सकता है

Robin Dunbar ने इसे प्राइमेट्स के मस्तिष्क के आकार और सामाजिक समूह के आकार के संबंध से निकाला
Dunbar की social hierarchy: ~5 लोग (घनिष्ठ संबंध), ~15 लोग (विश्वसनीय सहयोगी), ~50 लोग (करीबी कार्य-संबंध), ~150 लोग (स्थिर सामाजिक जुड़ाव)
इंजीनियरिंग संगठन 150 से अधिक होने पर अनौपचारिक संचार अपनी सीमा पर पहुँच जाता है, इसलिए औपचारिक hierarchy और process की ज़रूरत पड़ती है
Amazon की "Two-Pizza Team" (5~10 लोग) यह दर्शाती है कि 150 लोगों के भीतर भी वास्तविक सहयोग छोटे समूहों में होता है

4. Ringelmann प्रभाव (The Ringelmann Effect)

> जैसे-जैसे समूह का आकार बढ़ता है, व्यक्ति की प्रोडक्टिविटी घटती है

समूह के सदस्य बढ़ने पर प्रत्येक व्यक्ति का योगदान घटने की "social loafing" घटना
सॉफ़्टवेयर टीमों में भी टीम आकार बढ़ने पर व्यक्तिगत जवाबदेही कमजोर पड़ती है और coordination cost बढ़ती है
यह समझाता है कि छोटी टीमें प्रति व्यक्ति अधिक output क्यों देती हैं

5. Price का नियम (Price's Law)

> कुल प्रतिभागियों की संख्या के वर्गमूल के बराबर लोग कुल काम का 50% करते हैं

100 लोगों के संगठन में लगभग 10 लोग कुल काम का आधा संभालते हैं
संगठन जितना बड़ा होता है, उतना ही कुछ उच्च-प्रदर्शन करने वालों पर निर्भरता बढ़ती है
यह बताता है कि टीम बढ़ाने पर प्रोडक्टिविटी रैखिक रूप से क्यों नहीं बढ़ती

6. Putt का नियम (Putt's Law)

> जो लोग तकनीक को समझते हैं, वे प्रबंधन नहीं करते; और जो प्रबंधन करते हैं, वे तकनीक को नहीं समझते

तकनीकी संगठनों में management role और technical expertise के बीच की दूरी को व्यंग्यात्मक ढंग से व्यक्त करता है
technical leadership structure डिज़ाइन करते समय इस अंतर को पहचानना और संतुलन के उपाय बनाना ज़रूरी है

7. Peter सिद्धांत (Peter Principle)

> संगठन में हर कर्मचारी अपने अयोग्यता-स्तर तक पदोन्नत होने की प्रवृत्ति रखता है

किसी भूमिका में सक्षम व्यक्ति के पदोन्नत होकर नई भूमिका में अक्षम हो जाने का पैटर्न
यह उस वास्तविकता को दर्शाता है कि बेहतरीन डेवलपर ज़रूरी नहीं कि अच्छा मैनेजर भी बने
IC(Individual Contributor) ट्रैक और management ट्रैक को अलग रखने वाली dual ladder प्रणाली की आवश्यकता

8. Bus Factor

> टीम के न्यूनतम कितने लोगों के हटने से प्रोजेक्ट गंभीर जोखिम में पड़ सकता है

Bus Factor 1 होने का मतलब Single Point of Failure का मौजूद होना
knowledge sharing, pair programming और documentation के ज़रिए Bus Factor बढ़ाना महत्वपूर्ण है
code review और cross-training, Bus Factor सुधारने के व्यावहारिक तरीके हैं

9. Dilbert सिद्धांत (Dilbert Principle)

> कंपनियाँ नुकसान सीमित करने के लिए अक्षम कर्मचारियों को प्रबंधकीय भूमिकाओं में पदोन्नत करने की प्रवृत्ति रखती हैं

Scott Adams द्वारा प्रस्तावित एक व्यंग्यात्मक अवलोकन, जो Peter सिद्धांत का एक रूपांतर है
प्रबंधकीय पदों को वास्तविक कामकाज में सबसे कम नुकसान पहुँचाने वाली जगह मानने की विरोधाभासी संगठनात्मक घटना

योजना (Planning)

10. समयपूर्व अनुकूलन / Knuth का optimization सिद्धांत (Premature Optimization)

> समयपूर्व optimization सभी बुराइयों की जड़ है

Donald Knuth ने 1974 के एक पेपर में कहा: "लगभग 97% मामलों में छोटी-मोटी efficiency को नज़रअंदाज़ करना चाहिए"
कोड का लगभग 20% हिस्सा execution time का 80% लेता है, इसलिए बाकी 80% कोड को optimize करना बेकार हो सकता है
सही क्रम: पहले इसे चलने लायक बनाओ → फिर सही बनाओ → और ज़रूरत हो तो तेज़ बनाओ
optimized code अधिक complex हो जाता है, इसलिए profiling के माध्यम से वास्तविक bottleneck पहचानने के बाद ही optimization करना चाहिए

11. Parkinson का नियम (Parkinson's Law)

> काम उतना फैल जाता है जितना समय उसके लिए उपलब्ध हो

अगर deadline 2 हफ़्ते की हो तो काम 2 हफ़्ते तक, और 4 हफ़्ते की हो तो 4 हफ़्ते तक फैल जाता है
यही वजह है कि सॉफ़्टवेयर प्रोजेक्ट में छोटे और स्पष्ट milestones तय करना ज़रूरी है
sprint-आधारित Agile इस नियम के प्रति एक व्यावहारिक प्रतिक्रिया है

12. 90-90 नियम (The Ninety-Ninety Rule)

> कोड का पहला 90% विकास समय का 90% लेता है, और बाकी 10% फिर एक और 90% समय लेता है

चेतावनी देता है कि सॉफ़्टवेयर प्रोजेक्ट का आख़िरी 10% (edge cases, polishing, bug fixes) अनुमान से कहीं ज़्यादा समय लेता है
"लगभग पूरा हो गया" वास्तव में पूरे शेड्यूल के मध्य बिंदु के बराबर हो सकता है

13. Hofstadter का नियम (Hofstadter's Law)

> Hofstadter के नियम को ध्यान में रखने पर भी चीज़ें हमेशा अनुमान से ज़्यादा समय लेती हैं

recursive self-reference वाली संरचना का नियम, जो सॉफ़्टवेयर schedule estimation की मूलभूत कठिनाई को व्यक्त करता है
buffer जोड़ने पर भी deadline पार हो जाने की वास्तविकता
Douglas Hofstadter ने इसे 1979 की पुस्तक Gödel, Escher, Bach में पेश किया

14. Goodhart का नियम (Goodhart's Law)

> जब कोई मापदंड लक्ष्य बन जाता है, तो वह अच्छा मापदंड नहीं रहता

code coverage को KPI बनाने पर बेकार टेस्टों की भरमार हो जाना इसका प्रतिनिधि उदाहरण है
code line count (LOC) से प्रोडक्टिविटी मापने पर अनावश्यक रूप से लंबा-चौड़ा कोड बनने लगता है
metric optimization नहीं, बल्कि मूल्यवान परिणाम हासिल करने पर ध्यान देना चाहिए

15. Gilb का नियम (Gilb's Law)

> जिस चीज़ को quantify करना ज़रूरी है, उसे बिल्कुल न मापने से बेहतर है कि किसी न किसी तरह मापा जाए

भले ही perfect measurement संभव न हो, अनुमानित measurement भी no measurement से हमेशा बेहतर होता है
सॉफ़्टवेयर क्वालिटी, user satisfaction जैसे कठिन-से-quantify क्षेत्रों पर भी लागू

आर्किटेक्चर (Architecture)

16. Hyrum का नियम (Hyrum's Law)

> अगर API उपयोगकर्ता पर्याप्त संख्या में हों, तो सिस्टम के हर observable behavior पर कोई न कोई निर्भर हो जाएगा

सिर्फ़ औपचारिक API spec ही नहीं, बल्कि timing, error message format, sorting order जैसे अनौपचारिक व्यवहार भी dependency बन जाते हैं
Microsoft Windows ने अतीत में document न किए गए behavior और bugs पर निर्भर third-party apps की compatibility बनाए रखने के लिए पुराने version का behavior कायम रखा
Google के Hyrum Wright ने 2011-2012 के आसपास Google की internal libraries में बदलाव के अनुभव से इसे देखा
सहकर्मी Titus Winters ने इसका नाम "Hyrum's Law" रखा (Software Engineering at Google में शामिल)
वास्तविक contract औपचारिक API नहीं, बल्कि पूरा observed behavior होता है

17. Gall का नियम (Gall's Law)

> कोई भी काम करने वाला जटिल system अनिवार्य रूप से किसी काम करने वाले सरल system से विकसित हुआ होता है

अगर शुरू से ही जटिल system design किया जाए, तो unvalidated unknown variables बहुत ज़्यादा होने के कारण failure की संभावना बढ़ जाती है
MVP (Minimum Viable Product) approach का सैद्धांतिक आधार
Facebook का 2004 में Harvard छात्रों के लिए एक सरल profile system से शुरू होकर धीरे-धीरे expand होने का उदाहरण
microservices में transition करते समय भी monolith से शुरू करके धीरे-धीरे अलग करना अधिक फ़ायदेमंद होता है
John Gall ने 1975 की अपनी पुस्तक Systemantics में इसे प्रस्तुत किया (30 publishers के इंकार के बाद प्रकाशित हुई cult classic)

18. Leaky Abstractions का नियम (The Law of Leaky Abstractions)

> हर non-trivial abstraction किसी न किसी हद तक leak करती है

ORM, SQL को छिपाता है, लेकिन performance problem आने पर अंततः generated query देखनी ही पड़ती है — यह इसका प्रतिनिधि उदाहरण है
Java/Python का garbage collection भी abstraction है, लेकिन GC pause जैसे internal behavior performance को प्रभावित करते हैं
सबक यह नहीं कि abstraction बुरी है, बल्कि यह कि abstraction टूटने की स्थिति के लिए तैयार रहना चाहिए
Joel Spolsky ने 2002 की blog post में TCP, virtual memory आदि के उदाहरणों के साथ इसे समझाया
George Box के "सभी models गलत होते हैं, लेकिन कुछ उपयोगी होते हैं" से भी इसका संदर्भ जुड़ता है

19. Tesler का नियम / Complexity Preservation का नियम (Tesler's Law)

> हर application में कुछ ऐसी अंतर्निहित complexity होती है जिसे हटाया नहीं जा सकता; उसे सिर्फ़ स्थानांतरित किया जा सकता है

मुख्य सवाल: complexity का बोझ कौन उठाएगा (user vs system)
Calendly scheduling coordination की complexity को system में absorb करता है, जबकि email threads उसे users पर डाल देते हैं
अच्छा design complexity को user experience से system के भीतर ले जाता है
Larry Tesler ने Apple Lisa और शुरुआती GUI पर काम करते समय 1980s में इसे स्थापित किया

20. CAP प्रमेय (CAP Theorem)

> distributed systems, consistency (C), availability (A), और partition tolerance (P) में से केवल दो की गारंटी दे सकते हैं

network partition वास्तविक दुनिया में अपरिहार्य है, इसलिए व्यवहारिक विकल्प consistency vs availability का होता है
CP systems (उदा.: MongoDB): partition होने पर writes रोककर सभी replicas का synchronization बनाए रखते हैं
AP systems (उदा.: Cassandra, DNS): partition के दौरान भी requests का जवाब देते रहते हैं और replicas के बीच अस्थायी inconsistency स्वीकार करते हैं
Eric Brewer ने 2000 में web services के संदर्भ में इसे प्रस्तावित किया, और Gilbert & Lynch ने 2002 में इसका औपचारिक प्रमाण दिया

21. Second-System Effect

> छोटे और सफल system के बाद अक्सर अत्यधिक design किया गया फूला हुआ अगला system आता है

पहले system की सफलता से आत्मविश्वास पाकर दूसरे system में सारे ideas भर देने का pattern
feature creep और over-generalization इसके मुख्य कारण हैं
Frederick Brooks ने The Mythical Man-Month में इसकी पहचान की

22. Distributed Computing की भ्रांतियाँ (Fallacies of Distributed Computing)

> distributed systems को पहली बार design करने वाले लोग अक्सर 8 गलत धारणाएँ बना लेते हैं

8 भ्रांतियाँ: (1) network भरोसेमंद है, (2) latency 0 है, (3) bandwidth अनंत है, (4) network सुरक्षित है, (5) topology नहीं बदलती, (6) administrator एक ही है, (7) transport cost 0 है, (8) network homogeneous है
इन धारणाओं के आधार पर design करने पर production में अनपेक्षित failures और performance problems आती हैं

23. अनपेक्षित परिणामों का नियम (Law of Unintended Consequences)

> जटिल system में बदलाव करने पर अनपेक्षित परिणामों की अपेक्षा रखनी चाहिए

system के एक component को बदलने पर ऐसी जगहों पर भी side effects हो सकते हैं जिनका अनुमान नहीं था
chaos engineering और comprehensive testing की ज़रूरत को समर्थन देने वाला सिद्धांत

24. Zawinski का नियम (Zawinski's Law)

> हर program तब तक expand होने की कोशिश करता है जब तक वह mail पढ़ने में सक्षम न हो जाए

software सफल होने पर उसमें लगातार और अधिक features जोड़ने की feature bloat प्रवृत्ति पर यह व्यंग्य है
Jamie Zawinski (Netscape के शुरुआती developer) ने इसे देखा
यह चेतावनी है कि साधारण tools समय के साथ all-purpose platform बनने लगते हैं

गुणवत्ता (Quality)

25. Boy Scout नियम (The Boy Scout Rule)

> code को उससे बेहतर स्थिति में छोड़ना चाहिए, जितनी स्थिति में वह मिला था

बड़े refactoring की जगह लगातार और क्रमिक सुधार इसका मूल है
उलझे हुए function names को ठीक करना, duplicate code हटाना, missing tests जोड़ना — यानी हर बार छोटे सुधार करना
Robert C. Martin (Uncle Bob) ने Clean Code (2008) में इसे software development पर लागू किया
Google engineers का सिद्धांत "If you touch it, you own it" — code बदलते ही उसकी quality की ज़िम्मेदारी भी आपकी होती है
इस नियम का पालन करने से Broken Windows effect को रोका जा सकता है और technical debt जमा होने से बचता है

26. Murphy का नियम (Murphy's Law)

> जो कुछ गलत हो सकता है, वह गलत होकर रहेगा

defensive programming, exception handling, और failure-ready design का आधार
software में "जो error हो सकती है, वह ज़रूर होगी" की सोच के साथ error handling और fallback design करना चाहिए

27. Postel का नियम / Robustness Principle (Postel's Law)

> जो आप भेजते हैं उसमें conservative रहें, और जो दूसरों से प्राप्त करते हैं उसमें liberal रहें

API design में output spec का सख़्ती से पालन करे, लेकिन input के लिए विभिन्न formats को लचीले ढंग से स्वीकार करे — यही सिद्धांत है
Jon Postel ने TCP/IP protocol design के दौरान इस Robustness Principle को स्थापित किया
systems के बीच interoperability बढ़ाने के लिए यह एक व्यावहारिक guideline है

28. Broken Windows Theory

> खराब design, गलत निर्णय, और low-quality code को अनदेखा न करें

अगर एक "broken window" (खराब code) को छोड़ दिया जाए, तो वह गुणवत्ता में और गिरावट को जन्म देता है
codebase में TODO comments, dead code, unresolved warnings जमा होने लगें, तो नया code भी निम्न स्तर का लिखे जाने की प्रवृत्ति बनती है
छोटी से छोटी समस्या को भी मिलते ही ठीक करने वाली संस्कृति महत्वपूर्ण है

29. Technical Debt

> software development की गति को धीमा करने वाले सभी तत्व

Ward Cunningham ने 1992 के OOPSLA में इसे पहली बार financial metaphor के रूप में इस्तेमाल किया: code shortcut लेने का मतलब भविष्य से समय उधार लेना है
principal (fixing cost) + interest (गंदे code की वजह से productivity में लगातार गिरावट)
जानबूझकर लिया गया technical debt कभी-कभी उचित हो सकता है (market launch timing, prototyping), लेकिन repayment plan ज़रूरी है
automation tests को छोड़ देना इसका प्रतिनिधि उदाहरण है: release सफल हो जाती है, लेकिन बाद के हर बदलाव पर अनपेक्षित bugs आते हैं
समाधान: refactoring, missing tests जोड़ना, design सुधारना

30. Linus का नियम (Linus's Law)

> यदि reviewers की संख्या पर्याप्त हो, तो हर bug आसानी से दिखाई देने लगता है

open source development का मुख्य सिद्धांत: ज़्यादा लोगों की नज़र code की समीक्षा करे तो bugs मामूली समस्या बन जाते हैं
Eric Raymond ने The Cathedral and the Bazaar में Linus Torvalds के नाम पर यह नाम दिया
code review culture के महत्व को मज़बूती देता है

31. Kernighan का नियम (Kernighan's Law)

> debugging, code को पहली बार लिखने से दोगुनी कठिन होती है

इसलिए अगर आप कोड को जितना हो सके उतना चालाकी से लिखते हैं, तो debugging करते समय उतने चालाक नहीं रह जाते
यही वजह है कि उच्च पठनीयता वाला सरल कोड लिखना चाहिए
Brian Kernighan ने The Elements of Programming Style में प्रस्तुत किया

32. Testing Pyramid

> किसी प्रोजेक्ट में बहुत सारे तेज unit tests, कम integration tests, और बहुत कम UI tests होने चाहिए

Unit tests (निचला स्तर): तेज और कम लागत वाले, सबसे अधिक लिखे जाते हैं
Integration tests (मध्य): components के बीच interaction को verify करते हैं
UI/E2E tests (ऊपरी स्तर): धीमे और आसानी से टूटने वाले, इसलिए इन्हें न्यूनतम रखें
Mike Cohn ने Succeeding with Agile में इस testing strategy model का परिचय दिया

33. Pesticide Paradox

> एक ही test को बार-बार चलाने पर समय के साथ उसकी प्रभावशीलता घट जाती है

मौजूदा tests जिन bugs को पकड़ सकते थे, वे पहले ही पकड़ चुके होते हैं, इसलिए नए test cases लगातार जोड़ने चाहिए
test set की नियमित समीक्षा और update आवश्यक है

34. Lehman's Laws of Software Evolution

> वास्तविक दुनिया को प्रतिबिंबित करने वाला software अनिवार्य रूप से evolve करता है, और इस evolution की कुछ पूर्वानुमेय सीमाएँ होती हैं

E-type (वास्तविक दुनिया को प्रतिबिंबित करने वाला) software उपयोगी बने रहने के लिए लगातार बदलाव मांगता है
हर बदलाव के साथ complexity बढ़ती है, और यदि इसे सक्रिय रूप से manage न किया जाए तो quality गिरती है

35. Sturgeon's Law

> हर चीज़ का 90% बेकार होता है

Theodore Sturgeon ने इसे science fiction साहित्य की आलोचना के जवाब में प्रस्तुत किया
software पर भी लागू: अधिकांश code, tools, और frameworks में से वास्तव में उत्कृष्ट चीज़ें बहुत कम होती हैं
quality के लिए ऊँचे मानदंड बनाए रखें और मूल्यवान 10% पर ध्यान दें

Scale

36. Amdahl's Law

> parallelization से मिलने वाली speedup उस काम के हिस्से से सीमित होती है जिसे parallel नहीं किया जा सकता

अगर program का 5% हिस्सा sequential है, तो चाहे कितने भी processors लगा दें, सैद्धांतिक अधिकतम speedup 20x ही होगा
parallelization की सीमाएँ समझना और sequential bottleneck को कम करना अधिक प्रभावी है
Gene Amdahl ने 1967 में यह सिद्धांत प्रस्तुत किया

37. Gustafson's Law

> problem size बढ़ाकर parallel processing में उल्लेखनीय speedup हासिल की जा सकती है

Amdahl's Law पर पूरक दृष्टिकोण: fixed problem की बजाय scalable problems में processors बढ़ाना प्रभावी होता है
big data processing, scientific simulations आदि में अधिक resources के साथ बड़े problems हल किए जा सकते हैं

38. Metcalfe's Law

> किसी network का मूल्य उसके users की संख्या के वर्ग के अनुपात में बढ़ता है

अगर users 10 हैं तो मूल्य 100 units, और 100 users होने पर 10,000 units तक बढ़ता है
social networks, messengers, marketplaces आदि में network effect का सैद्धांतिक आधार
Robert Metcalfe ने Ethernet तकनीक के मूल्य को समझाने के लिए इसे प्रस्तुत किया

Design

39. DRY सिद्धांत (Don't Repeat Yourself)

> हर knowledge का केवल एक ही एकल, स्पष्ट और authoritative representation होना चाहिए

इसमें सिर्फ code duplication ही नहीं, बल्कि knowledge, logic, और data की duplication भी शामिल है
duplication के कारण बदलाव के समय कई जगह एक साथ संशोधन करना पड़ता है, जिससे bugs और inconsistency पैदा होती है
Andy Hunt और Dave Thomas ने The Pragmatic Programmer में इसे स्थापित किया

40. KISS सिद्धांत (Keep It Simple, Stupid)

> design और systems को जितना संभव हो उतना सरल होना चाहिए

complexity, समझने, maintenance, और debugging की लागत बढ़ाती है
सरल समाधान अधिकांश मामलों में अधिक प्रभावी होते हैं और उनमें defects की संभावना भी कम होती है
इसकी उत्पत्ति 1960 के दशक में अमेरिकी नौसेना के design principle से हुई

41. SOLID Principles

> software design को बेहतर बनाने वाले 5 मुख्य guidelines

S — Single Responsibility Principle: class में बदलाव का केवल एक ही कारण होना चाहिए
O — Open-Closed Principle: extension के लिए खुला और modification के लिए बंद होना चाहिए
L — Liskov Substitution Principle: subtypes को supertypes की जगह इस्तेमाल किया जा सके
I — Interface Segregation Principle: clients को उन interfaces पर निर्भर नहीं होना चाहिए जिनका वे उपयोग नहीं करते
D — Dependency Inversion Principle: high-level modules को low-level modules पर नहीं, abstraction पर निर्भर होना चाहिए
Robert C. Martin ने इसे स्थापित किया और Michael Feathers ने SOLID acronym नाम दिया

42. Demeter का नियम (Law of Demeter)

> objects को केवल अपने सीधे मित्रों के साथ interact करना चाहिए, अनजान objects के साथ सीधे संचार से बचना चाहिए

a.getB().getC().doSomething() जैसे chain calls से बचने का सिद्धांत
coupling को कम करता है और encapsulation को मजबूत बनाकर बदलाव के प्रभाव-क्षेत्र को घटाता है
इसे "principle of least knowledge" भी कहा जाता है

43. Principle of Least Astonishment

> software और interfaces को इस तरह काम करना चाहिए कि वे users और अन्य developers को सबसे कम चौंकाएँ

functions, API, और UI को naming और conventions के हिसाब से predictable behavior दिखाना चाहिए
अगर delete() function वास्तव में केवल archive करता है, तो यह आश्चर्य पैदा करता है → design defect
गैर-स्वाभाविक behavior bugs और user mistakes को जन्म देता है

44. YAGNI (You Aren't Gonna Need It)

> ज़रूरत पड़ने से पहले features मत जोड़ो

Extreme Programming (XP) का मुख्य सिद्धांत, जिसे 1990 के दशक के अंत में Ron Jeffries ने प्रस्तुत किया
"शायद भविष्य में ज़रूरत पड़े" सोचकर code लिखने से overengineering और maintenance burden पैदा होता है
YAGNI को व्यवहार में लाने के लिए refactoring पर आत्मविश्वास (अच्छी test coverage, CI) होना चाहिए
अगर अभी केवल JSON export चाहिए, तो सिर्फ JSON implement करें; XML/YAML आदि तब जोड़ें जब वास्तव में माँग हो

निर्णय (Decisions)

45. Dunning-Kruger Effect

> किसी विषय के बारे में जितना कम पता होता है, उतना अधिक आत्मविश्वास होने की प्रवृत्ति रहती है

नए developers अक्सर complex systems की कठिनाई को कम आँकते हैं, जबकि experts कभी-कभी अपने ज्ञान के प्रति अधिक विनम्र होते हैं
code review, mentoring, और निरंतर learning के माध्यम से self-awareness की सटीकता बढ़ाना महत्वपूर्ण है

46. Hanlon's Razor

> जिसे मूर्खता या लापरवाही से पर्याप्त रूप से समझाया जा सकता है, उसे दुर्भावना मत मानो

किसी सहकर्मी के खराब code या गलत निर्णय को जानबूझकर की गई बाधा मानने से पहले अज्ञानता, गलती, या समय की कमी पर विचार करें
यह टीम के भीतर trust और constructive communication की बुनियाद है

47. Occam's Razor

> अक्सर सबसे सरल व्याख्या ही सबसे सही होती है

debugging के समय जटिल कारणों से पहले सबसे सरल संभावना की जाँच करें
architecture design में भी अनावश्यक abstraction layers जोड़ने से पहले सरल समाधान तलाशें

48. Sunk Cost Fallacy

> सिर्फ इसलिए नुकसानदेह विकल्प पर टिके रहना क्योंकि उसमें पहले ही समय या ऊर्जा निवेश की जा चुकी है

6 महीने तक विकसित किया गया feature गलत दिशा में हो, फिर भी लगाए गए समय की वजह से उसे छोड़ न पाना इसी मनोवृत्ति का उदाहरण है
सही निर्णय का आधार पिछला निवेश नहीं, बल्कि भविष्य का मूल्य होना चाहिए

49. The Map Is Not the Territory

> वास्तविकता का representation (model) स्वयं वास्तविकता के बराबर नहीं होता

UML diagrams, architecture documents, data models आदि केवल वास्तविकता के approximation हैं
models पर अंधविश्वास न करें; वास्तविक system के behavior को देखकर उन्हें update करना चाहिए

50. Confirmation Bias

> अपनी मौजूदा मान्यताओं या विचारों का समर्थन करने वाली जानकारी को प्राथमिकता देने की प्रवृत्ति

अपने चुने हुए tech stack या design decision के पक्ष में ही जानकारी चुन-चुनकर इकट्ठा करने का जाल
विरोधी प्रमाण सक्रिय रूप से खोजने और अलग-अलग दृष्टिकोण स्वीकार करने में ही संतुलित decision-making की कुंजी है

51. Hype Cycle और Amara का नियम (The Hype Cycle & Amara's Law)

तकनीक के अल्पकालिक प्रभावों को बढ़ा-चढ़ाकर आँकने और दीर्घकालिक प्रभावों को कम आँकने की प्रवृत्ति होती है

Gartner का Hype Cycle: तकनीकी ट्रिगर → अत्यधिक अपेक्षाओं का शिखर → मोहभंग की घाटी → ज्ञानोदय की ढलान → उत्पादकता का स्थिर चरण
नई तकनीक (blockchain, AI आदि) अपनाते समय अल्पकालिक उत्साह में बहने के बजाय दीर्घकालिक व्यावहारिकता का मूल्यांकन करना चाहिए

52. Lindy प्रभाव (The Lindy Effect)

जो चीज़ जितने लंबे समय से उपयोग में है, उसके आगे भी उपयोग में बने रहने की संभावना उतनी अधिक होती है

UNIX, SQL, C भाषा जैसी दशकों से उपयोग में रही तकनीकों के आगे भी लंबे समय तक टिके रहने की संभावना अधिक होती है
नए framework की तुलना में परखी हुई तकनीक चुनने का सैद्धांतिक आधार
Nassim Nicholas Taleb ने इसे Antifragile में लोकप्रिय बनाया

53. प्रथम सिद्धांत सोच (First Principles Thinking)

जटिल समस्या को उसके सबसे बुनियादी घटकों में तोड़कर फिर उनसे दोबारा निर्मित करने की सोच

मौजूदा प्रथाओं और मान्यताओं को हटाकर मूलभूत सत्य से शुरुआत करते हुए समाधान निकाला जाता है
Elon Musk द्वारा SpaceX रॉकेट लागत कम करने में इसके उपयोग का उदाहरण प्रसिद्ध है
जटिल system design करते समय "हमेशा से ऐसा ही होता आया है" जैसी सोच से सावधान रहना चाहिए

54. उलटी सोच (Inversion)

विपरीत परिणाम की कल्पना करके उलटी दिशा से तर्क कर समस्या हल करने का तरीका

"सफल कैसे हों" के बजाय पहले "असफल कैसे हों" के बारे में सोचकर जोखिम कारकों की पहचान की जाती है
failure mode analysis और pre-mortem का सैद्धांतिक आधार
Charlie Munger द्वारा अक्सर इस्तेमाल किया जाने वाला mental model

55. Pareto Principle / 80/20 नियम (Pareto Principle)

समस्या का 80% उसके 20% कारणों से पैदा होता है

कुल bugs का 80% अक्सर code के 20% हिस्से में केंद्रित पाया जाता है
सबसे अधिक प्रभाव वाले 20% पर resources केंद्रित करना संसाधनों के कुशल आवंटन की रणनीति है
यह Vilfredo Pareto द्वारा इटली में भूमि स्वामित्व के वितरण के अवलोकन से निकले सिद्धांत पर आधारित है

56. Cunningham का नियम (Cunningham's Law)

इंटरनेट पर सही जवाब पाने का सबसे अच्छा तरीका सवाल पूछना नहीं, बल्कि गलत जवाब पोस्ट करना है

लोग सवालों के जवाब देने से अधिक गलत जानकारी को सुधारने में सक्रिय रूप से भाग लेते हैं
यह Ward Cunningham (Wiki के आविष्कारक) के नाम पर है, लेकिन वास्तव में यह नाम Steven McGeady ने दिया था
open source community में documentation या knowledge sharing के लिए उपयोगी अंतर्दृष्टि