Occam’s Razor in Software Development

Occam’s razor is one of the most powerful problem solving principles applicable in life and in software development. It is probably not well known, is often misunderstood and under-utilised.

In this post, I disambiguate it, enumerate multiple formulations and common misinterpretations. I will demonstrate that many principles and practices in software development are applications of Occam’s razor, and list some missed opportunities.

The premise of Occam’s razor is that “entities should not be multiplied without necessity”. It advocates that when presented with competing hypotheses about the same prediction, one should select the solution with the fewest assumptions, and that this is not meant to be a way of choosing between hypotheses that make different predictions. -Ⓐ

It is often mistaken to advocate simplicity, but has a more nuanced recommendation, which is described by the quote “Everything should be made as simple as possible, but no simpler.” -Ⓑ Wikipedia has more formulations of this principle “It is vain to do with more what can be done with fewer”-Ⓒ

In the world of predictive models one needs to maintain balance between model complexity and error, which would be a sweet spot is between over-generalization and over-specialization.

This leads to yet another formulation “reduce complexity, if and only if you can” -Ⓓ


There are two different maps of the Bengaluru metro, both of which show the green line. Both of them show the ordering of stations, while the first of them captures the physical orientation as well. Is the first map conformant to Occam’s razor or is it the second? well, it depends on the problem in hand. This illustrates another observation on Occam’s razor, “it is contextual. The best hypothesis in one context, needn’t be the best in another.

Essential vs Accidental Complexity

The philosophy of “Manage Essential complexity and reduce/eliminate Accidental Complexity” is a key application of Occam’s Razor.





Encapsulation is the grouping of related ideas into one unit, which can thereafter be referred to by a single name” — Meilir Page-Jones

Generalization by encapsulation reduces the amount of information in your code.



Dependency inversion

Higher Order Functions

Parametric polymorphism

Higher Kinded Types


Salient features of platforms are that production and value creation happen outside of the platform. The interaction between producers and consumers is the value creation activity. Note that for the platform the producers and consumers are parameters.


Information Hiding

Interface Segregation principle

Composition over inheritance


Essence over ceremony



Loose Coupling

High Cohesion

Type 1 and Type 2 errors

In the context of the above diagram, h₃ is the best solution, even if h₁makes fewer assumptions

Decision making can make mistakes on both fronts. The following memes capture two kinds of errors, depicting perils of over emphasis on single criteria

Errors in hypothesis selection can be categorised into two types.

  1. where an incorrect hypothesis is chosen
  2. where an inefficient hypothesis is chosen


Type 1

Boxes and Arrows

Anemic Domain Model

This kind of weak information hiding is the basis of the Anemic Domain Model anti-pattern which unfortunately is quite prevalent.

Bad Names

Type 2

Code as (the only) model

Long names

Unwarranted Agglutination

P.S the pictures used are from google searches and from a slide deck from Kevlin Henney