More_Laws

_laws/amdahl.md

@@ -0,0 +1,26 @@
+---
+layout: post
+title: Amdahl's Law
+law: The speedup of a program using multiple processors is limited by the sequential portion of the program.
+law-author: Gene Amdahl
+law-url: https://en.wikipedia.org/wiki/Amdahl%27s_law
+law-year: 1967
+---
+
+# Amdahl's Law
+
+**Description:**  
+Amdahl's Law, introduced by Gene Amdahl in 1967, explains the limitations of parallel processing. It states that the potential speedup of a program by parallelization is constrained by the portion of the program that must be executed sequentially. Even with infinite processors, the speedup is capped by the time spent on the sequential part.
+
+**Implications in Software Engineering:**  
+- Encourages careful analysis of which parts of a program can be parallelized.
+- Highlights diminishing returns when adding more processors beyond a certain point.
+- Useful in optimizing multi-threaded applications and understanding scalability limits.
+
+**Example:**  
+If 90% of a program can be parallelized and 10% must remain sequential, the maximum theoretical speedup, regardless of the number of processors, is 10x.
+
+**Reference:**  
+[Amdahl's Law on Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)
+
+- [Modeling critical sections in Amdahl's law and its implications for multicore design](https://dl.acm.org/doi/10.1145/1815961.1816011)

_laws/boyds_law_of_iteration.md

@@ -0,0 +1,26 @@
+---
+layout: post
+title: Boyd's Law of Iteration
+law: Speed of iteration beats quality of iteration
+law-author: John Boyd
+law-url: https://blog.codinghorror.com/boyds-law-of-iteration/
+law-year: Around 1987
+---
+
+# Boyd's Law of Iteration
+
+**Description:**  
+Boyd's Law of Iteration, named after military strategist John Boyd, suggests that faster iterations beat slower ones in competitive environments. It emphasizes continuous feedback loops and rapid development to outpace competitors.
+
+**Implications in Software Engineering:**  
+- Encourages agile methodologies that promote short development cycles and quick feedback.
+- Improves adaptability to changing requirements and user needs.
+
+**Example:**  
+Agile sprints are an example of rapid iteration, allowing teams to deliver incremental updates and adjust based on user feedback.
+
+**Reference:**  
+[John Boyd's OODA Loop](https://en.wikipedia.org/wiki/John_Boyd_(military_strategist)#OODA_loop) (Observe, Orient, Decide, Act) concept in strategic thinking.
+
+- https://www.mikemcgarr.com/blog/boyds-law-of-iteration.html
+- https://blog.codinghorror.com/boyds-law-of-iteration/

_laws/law_of_the_instrument.md

@@ -0,0 +1,26 @@
+---
+layout: post
+title: Law of the Instrument (Golden Hammer)
+law: If all you have is a hammer, everything looks like a nail.
+law-author: Abraham Maslow
+law-url: https://en.wikipedia.org/wiki/Law_of_the_instrument
+law-year: 1966
+---
+
+# Law of the Instrument (Golden Hammer)
+
+**Description:**  
+The Law of the Instrument, often summarized as "If all you have is a hammer, everything looks like a nail," warns against over-relying on familiar tools or methods. This principle, introduced by Abraham Maslow in 1966, emphasizes the importance of selecting the right tool or approach based on the specific problem, rather than defaulting to what is most familiar.
+
+**Implications in Software Engineering:**  
+- Encourages developers to evaluate the suitability of technologies, frameworks, or methodologies before applying them to a problem.
+- Helps avoid technical debt by promoting diversity in toolsets and solutions.
+- Supports innovation by challenging the status quo and exploring alternatives.
+
+**Example:**  
+A developer who only knows one programming language might attempt to use it for every project, even when a different language would be more appropriate, such as using a web framework for a data-heavy batch processing job.
+
+**Reference:**  
+[Law of the Instrument on Wikipedia](https://en.wikipedia.org/wiki/Law_of_the_instrument)
+
+- [The psychology of science: a reconnaissance](https://www.semanticscholar.org/paper/The-psychology-of-science%3A-a-reconnaissance-Maslow/9e0ccd3915fb45adcfd071e6762bc5733eca534a)

_laws/liskov_substitution_principle.md

@@ -0,0 +1,30 @@
+Here’s **Liskov Substitution Principle (LSP)** in the requested style:
+
+
+---
+layout: post
+title: Liskov Substitution Principle (LSP)
+law: Objects of a superclass should be replaceable with objects of a subclass without altering program correctness.
+law-author: Barbara Liskov
+law-url: https://en.wikipedia.org/wiki/Liskov_substitution_principle
+law-year: 1987
+---
+
+# Liskov Substitution Principle (LSP)
+
+**Description:**  
+The Liskov Substitution Principle, introduced by Barbara Liskov in 1987, is a key component of object-oriented design. It states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. This ensures that inheritance strengthens a system's robustness rather than undermines it.
+
+**Implications in Software Engineering:**  
+- Promotes the design of classes that adhere to consistent behavior across hierarchies.
+- Enhances system scalability by ensuring that extending classes do not break established functionality.
+- Encourages adherence to interface contracts, ensuring predictable behavior.
+
+**Example:**  
+A classic violation of LSP occurs when a subclass overrides methods of a superclass in a way that alters expected behavior. For instance, if `Rectangle` has methods to set width and height independently, a subclass `Square` that forces width and height to be the same would violate LSP.
+
+**Reference:**  
+[Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
+
+- [Making the liskov substitution principle happy and sad](https://dl.acm.org/doi/10.1145/3183377.3183392)
+- [Evolving an integrated curriculum for object-oriented analysis and design](https://dl.acm.org/doi/10.1145/1352135.1352252)

_laws/murphy.md

@@ -0,0 +1,24 @@
+---
+layout: post
+title: Murphy's Law
+law: Anything that can go wrong, will go wrong.
+law-author: Edward A. Murphy Jr.
+law-url: https://en.wikipedia.org/wiki/Murphy%27s_law
+law-year: Around 1949
+---
+
+# Murphy's Law
+
+**Description:**  
+Murphy's Law, attributed to engineer Edward A. Murphy Jr. around 1949, states that "Anything that can go wrong, will go wrong." It serves as a reminder to expect the unexpected and account for potential failures, particularly in complex systems like software engineering.
+
+**Implications in Software Engineering:**  
+- Highlights the importance of robust testing, error handling, and contingency planning.
+- Encourages defensive programming techniques to anticipate and mitigate possible issues.
+- Underlines the need for thorough reviews and risk assessments, as even minor oversights can lead to significant problems.
+
+**Example:**  
+A classic manifestation of Murphy’s Law in software development is when a seemingly minor change in the codebase introduces unexpected bugs in unrelated parts of the system.
+
+**Reference:**  
+[Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)

_laws/pareto_principle.md

@@ -0,0 +1,26 @@
+---
+layout: post
+title: Pareto Principle (80/20 Rule)
+law: 80% of the effects come from 20% of the causes.
+law-author: Vilfredo Pareto
+law-url: https://en.wikipedia.org/wiki/Pareto_principle
+law-year: 1896
+---
+
+# Pareto Principle (80/20 Rule)
+
+**Description:**  
+The Pareto Principle, also known as the 80/20 Rule, was first observed by economist Vilfredo Pareto in 1896. It states that 80% of the results or effects in many systems come from 20% of the causes or inputs. In software development, this principle often manifests in code, where a small portion of the system's code provides the majority of its functionality or performance impact.
+
+**Implications in Software Engineering:**  
+- Helps developers focus on the 20% of features or code that deliver the most value to users.
+- Guides optimization efforts by prioritizing the most impactful areas, such as performance bottlenecks or critical bug fixes.
+- Encourages a balanced approach to feature development and maintenance.
+
+**Example:**  
+In many software systems, 80% of user complaints may stem from just 20% of the application’s codebase. By identifying and addressing this critical 20%, significant improvements can be made efficiently.
+
+**Reference:**  
+[Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
+
+- [Application of 80/20 rule in software engineering Waterfall Model](https://ieeexplore.ieee.org/document/5267186)