Why Knowing 100 Coding Principles Still Won’t Make You Write Good Code: The 4 Misunderstood Rules

Development principles – common misinterpretations

DRY (Don’t Repeat Yourself) is often taken to mean “no two similar code blocks may exist”. This leads to over‑abstracted frameworks that violate KISS (Keep It Simple, Stupid) because the solution’s complexity grows while the original intent of DRY is merely to avoid unnecessary duplication.

KISS means keeping the *solution* complexity low, not skipping required work.

YAGNI (You Aren’t Gonna Need It) warns against premature features; the mistake is to discard needed functionality because it “might” be unused.

Fail Fast is frequently read as “allow failure”. The correct meaning is to expose errors as early as possible, e.g., validate parameters at entry and throw exceptions rather than swallowing errors and surfacing them deep in the call stack.

Boy Scout Rule (leave the code cleaner than you found it) encourages incremental improvement—renaming a variable, extracting a function, or deleting dead code—rather than large‑scale refactoring.

Design principles – SOLID and dependency direction

SOLID (Robert C. Martin, 2000s) consists of five rules that share a single core idea: control the direction of dependencies so that high‑level modules depend on abstractions, not on low‑level details.

SRP – a module should have only one reason to change. Violation: a class mixes business logic and database access.

OCP – open for extension, closed for modification (originally proposed by Bertrand Meyer, 1988). Violation: adding a feature requires modifying existing code.

LSP – subclasses must be replaceable without breaking behavior (Barbara Liskov, 1987). Violation: overridden methods change expected behavior.

ISP – clients should not depend on interfaces they do not use. Violation: a “fat” interface forces implementers to support unnecessary methods.

DIP – high‑level modules should not depend on low‑level modules; both should depend on abstractions. Violation: business code directly instantiates a concrete database class.

These rules are the foundation of GoF’s 23 design patterns, GRASP’s nine patterns, and the package‑level cohesion and coupling principles that extend SOLID to component boundaries.

Architectural thinking – trade‑offs and impossibility

CAP theorem (Eric Brewer, 2000; formal proof by Gilbert & Lynch, 2002) is often misquoted as “choose any two”. In practice, network partitions are inevitable; the real choice is between consistency and availability when a partition occurs.

PACELC (Daniel Abadi, 2010) extends CAP: during a partition (P) trade‑off is between consistency (C) and availability (A); when there is no partition (E) the trade‑off is between latency (L) and consistency (C).

FLP impossibility theorem (Fischer, Lynch & Paterson, 1985) proves that deterministic consensus cannot be guaranteed in a fully asynchronous system, forcing designers to compromise between “always correct” and “eventually available”.

Postel’s law (Jon Postel, 1980) – “be strict in what you send, tolerant in what you accept” – guided early Internet protocols. Modern protocols such as HTTP/2 (RFC 7540, 2015) and gRPC adopt a stricter “send‑and‑receive” model, abandoning the tolerant‑receiver approach that created compatibility problems.

Engineering methodology – measurement paradox

Agile and Kanban are not merely daily stand‑ups or boards; their essence is limiting Work‑In‑Progress (WIP) to expose bottlenecks and shorten cycle time.

DevOps is defined as deep collaboration between development and operations, replacing siloed responsibilities with shared ownership.

DORA’s four metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore) and the SPACE framework (satisfaction, performance, activity, collaboration, efficiency) are tools for diagnosing team health, not KPI targets.

Goodhart’s law warns that once a metric becomes a target it ceases to be a good measure; examples include optimizing line count or bug count, which can lead to perverse outcomes.

Experience laws – empirical observations

Knuth (1974) observed that 97 % of code does not need aggressive optimization, but the critical 3 % must be measured and refined.

Pareto’s 80/20 law states that 80 % of results come from 20 % of causes; the “28 rule” is a mis‑translation that incorrectly reduces the percentages to 2 and 8.

Hyrum’s law notes that any observable behavior of an API can become an implicit contract once enough users depend on it, making seemingly harmless implementation details a source of breaking changes.

Hofstadter’s law (“it always takes longer than you expect, even when you take this law into account”) and Conway’s law (system architecture mirrors organizational communication structure) explain why projects often exceed estimates and why architecture reflects team boundaries. The Inverse Conway maneuver deliberately reshapes the organization first, allowing the architecture to follow.

Five‑layer framework

1. Development principles – govern individual lines of code (DRY, KISS, YAGNI, Fail Fast, Boy Scout).

2. Design principles – shape code organization and dependency direction (SOLID, GoF patterns, GRASP, package cohesion/coupling).

3. Architectural ideas – dictate system‑level trade‑offs (CAP, PACELC, FLP, Postel’s law).

4. Engineering methodology – guide team processes and measurement (Agile/Kanban WIP limits, DevOps collaboration, DORA & SPACE metrics, Goodhart’s law).

5. Experience laws – influence project outcomes (Knuth, Pareto, Hyrum, Hofstadter, Conway, Inverse Conway).

Understanding the original intent of each principle before discarding it helps locate problems within the appropriate layer.

References

Brooks, F. P. (1975). The Mythical Man‑Month . Addison‑Wesley.

Meyer, B. (1988). Object‑Oriented Software Construction . Prentice Hall.

Liskov, B. (1987). “Data Abstraction and Hierarchy”. SIGPLAN Notices 23(5).

Martin, R. C. (2000s). SOLID principles; Feathers, M. introduced the acronym.

Brewer, E. (2000). “Towards Robust Distributed Systems”. PODC.

Gilbert, S. & Lynch, N. (2002). “Brewer’s Conjecture…”. ACM SIGACT News.

Abadi, D. (2010). “Consistency Tradeoffs in Modern Distributed Database System Design”. IEEE Computer.

Fischer, M. J., Lynch, N. A., Paterson, M. S. (1985). “Impossibility of Distributed Consensus with One Faulty Process”. Journal of the ACM.

Postel, J. (1980). RFC 761 / RFC 793.

Knuth, D. (1974). “Structured Programming with go to Statements”. ACM Computing Surveys 6(4).

Forsgren, N. et al. DORA metrics.

Forsgren, N., Storey, M‑A., Maddila, C. et al. “The SPACE of Developer Productivity”. Queue 19(1), 2021.

Code example

11. Cockburn, A. (2005). "Hexagonal Architecture". — 六边形架构原始提出
12. Young, G. (2010). CQRS 模式原始提出；Young, G. 等推广 Event Sourcing / 2010s
13. Lewis, J. & Fowler, M. (2014). "Microservices". martinfowler.com. — 微服务概念推广
14. Postel, J. (1980). RFC 761 / RFC 793. — 鲁棒性原则原始提出；HTTP/2 (RFC 7540, 2015) 和 gRPC 对其的批评
15. Knuth, D. (1974). "Structured Programming with go to Statements".