One AWS senior principal engineer shared this Github repo with us: https://github.com/dwmkerr/hacker-laws ([PDF], [Podcast]). The compilation of “Hacker Laws” provides essential guidance distilled from decades of experience. Whether you’re designing a distributed system, optimizing performance, or leading a team, these principles offer valuable frameworks for approaching common challenges.
It’s a really good read. Here is the quick summary:
1. Amdahl’s Law
This law emphasizes the diminishing returns of parallel processing. While adding processors may improve system performance, the non-parallelizable portion of your program will limit the overall speedup. For engineers, this serves as a reminder to analyze the structure of the tasks before throwing hardware at the problem.
Key takeaway: Focus on optimizing the bottlenecks before investing in parallelization.
2. Brooks’ Law
The more people you add to a late project, the later it becomes. Brooks’ Law is a cautionary principle that illustrates the inefficiencies created by increased communication overhead and the learning curve of new team members.
Key takeaway: Adding more developers to a problem will not necessarily solve it faster; consider smarter resource allocation.
3. The Broken Windows Theory
This theory suggests that minor issues, like bad code quality or technical debt if left unchecked, will accumulate and eventually cause more significant problems. Treat your codebase like an environment—keep it clean to prevent long-term damage.
Key takeaway: Fix minor issues before they snowball into more significant, harder-to-manage problems.
4. CAP Theorem
The CAP theorem states that distributed systems can only guarantee two out of three properties: Consistency, Availability, and Partition Tolerance. This is critical when designing distributed applications, as you must prioritize based on your system’s needs.
Key takeaway: Understand the trade-offs in distributed systems and decide which aspects are most critical for your use case.
5. Conway’s Law
Organizations design systems that mirror their communication structures. If your company is divided into isolated teams, expect your systems to reflect this disjointed structure.
Key takeaway: Foster inter-team communication to build cohesive and unified system architectures.
6. The Pareto Principle (80/20 Rule)
In software development, 80% of the consequences come from 20% of the causes. The most critical features or bugs are often concentrated in a small portion of the codebase.
Key takeaway: Focus on the 20% of the work that drives 80% of the results—whether it’s features, bugs, or performance issues.
7. KISS (Keep It Simple, Stupid)
KISS advocates simplicity in design. Overcomplicating solutions makes them harder to maintain and scale. Always aim to solve problems with as little complexity as possible.
Key takeaway: Complexity is the enemy of reliability—choose simple, elegant solutions whenever possible.
8. YAGNI (You Aren’t Gonna Need It)
A principle from Extreme Programming, YAGNI advises against implementing features until necessary. Prematurely coding features that might never be used wastes time and resources.
Key takeaway: Build only what you need today, not what you anticipate needing tomorrow.
9. Linus’s Law
This law states, “Given enough eyeballs, all bugs are shallow.” In an open-source or collaborative environment, the more people reviewing the code, the easier it becomes to identify and fix bugs.
Key takeaway: Encourage code reviews and collaboration to uncover issues early.
10. The Law of Leaky Abstractions
Abstractions are necessary to simplify complexity, but every abstraction leaks some underlying complexity at critical moments. Engineers must be cautious about over-relying on abstractions without understanding the systems beneath them.
Key takeaway: Learn the inner workings of your abstractions so you’re prepared when things go wrong.
Final Thoughts: Understanding and applying these laws can elevate your engineering practices. They provide a lens through which to evaluate your design choices, team dynamics, and problem-solving approach. As the software development landscape evolves, these timeless principles remain crucial for success.