SOLID Principles and the Arts of Finding the Beach

If you look at the picture below I’m pretty sure you would find the beach following the sign would you?


Now imagine you wouldn’t know what a beach is, what would you do? Chances are that you miss the beach, swim around in the sea and finally write an angry blog post or tweet bashing the sign as totally misleading [5] and the person who put the sign here in the first place learns a invaluable lesson:

It is really hard to give guidance that is understood by everyone as it was originally intended.

Or modern world is running on computers and computers are fed with power and software so there is an ever increasing demand of skilled software developers to tell the computers what to do and when and how. Those software developers are coming from different countries with cultures, different education systems and experience so it’s increasingly hard to receive or give guidance without misunderstanding or being misunderstood.

Logic and Mathematics

Fortunately, we have methods in place that are thought in schools, colleges and universities all over the world, so they can be considered as commonly understood. They are called logic and mathematics [1]. The basic idea behind both can be described as follows:

  1. Set up general, arbitrary rules (also called assumptions or axioms).
  2. Draw conclusions that meet the given rules.
  3. Show unambiguously and in a way that is repeatable by anyone that your conclusions are consistent with the rules. This demonstration is called proof.

This method also called deduction might remind you of a game and this isn’t a coincidence. Every game has rules and every draw has to be consistent with the rules. Those rules are the same for every player and also accessible by anyone who is interested. But unlike most games, mathematics and logic aren’t based on competition, everyone can contribute and find a new conclusion and everybody who finds a new proof is a winner.


No doubt, the deductive method used in logic and mathematics is incredibly successful but it doesn’t tell you anything about the real world. This is because we don’t know what the rules of the world or the universe we live in actually are, nor do we know if such rules actually exist. So all we can do is observe the world, identify patterns and unify them into scientific laws or theories.  The method of gathering information and identifying patterns is called induction (not to be confuse with mathematical induction which is actually a form of deduction). It is also immensely successful but it has an obvious problem: We cannot observer everything that’s going on in the universe, hence our information thereof is always limited. So every scientific theory is only valid as long as nobody finds a counter example that renders the theory invalid or invalid under certain conditions.

Karl Popper illustrated the fundamental flaw of the inductive method with the following thought experiment [2]: Suppose you observe swans all your life and all you see is white swans, does this prove that all swans are black? No! You have no evidence that you have seen all swans and hence you cannot tell if there isn’t a swan on the planet that isn’t white.

Despite of this problem, science has served us pretty well. One reason for this is that it demands the same openness and transparency that logic and mathematics demand: Every theory can be verified or falsified by everyone else independent of the inventor of the theory. So over the years, generations of scientists had the opportunity to test and retest central scientific theories over and over again.

The Engineering Method

All fine but what does this tell us about software development or better software engineering? Engineering is all about building stuff and engineers use the theories of science as well as the methods of logic and mathematics but they are confronted with yet another problem: There is usually more than one way you can build something to implement a given functionality.

Fortunately, we have many constraints in traditional engineering. The vast majority of possible implementations would be too big, to heavy, consume too much energy, wouldn’t be possible to build or would be way too expensive. This is often very frustrating but at least we can find out what works and what not.

Due to the incredible flexibility of computers, the set of possible solutions is much larger in software engineering than in any other engineering discipline.

To find the right direction in the maze of possible solutions, engineers have developed “hint signs” named heuristics, rules of thumb , principles or laws [3]. They aren’t faintly as strict as rules or conclusions in mathematics nor as well tested as scientific theories, just useful little helpers that keep us from doing something we might regret later.

Back on the Beach

And here we are back on the beach. The sign isn’t meant to be a tool that defines precisely the location and geometry of the beach. It assumes that you know that you are on a beach when you are on a beach. It points in a direction and assumes that you know where to stop when you are there.

The same is true for the Principles of Object-Oriented Design aka SOLID Principles [4]. You need some experience with object-oriented software development in real world projects before they are of any use to you. Furthermore, they don’t tell you when you have found a good solution (the beach) and when you went too far (into the ocean). Going too far means that you are outside the “scope” of a principle and the expected advantages don’t appear.


Principles, Heuristics, ‘laws of engineering’ are like hint signs, they are helpful when you know where they are pointing to and you know when you have gone too far. Applying them requires experience, that is trying things out, failing, analysing, talking to people, failing again, fixing, learning and failing some more. There is no short cut as far as I know but if you find one, please leave me a comment!

Further Reading

[1] Bill Shilito:Introduction to Higher Mathematics, 2013,

[2] Wikiopedia on Falsifiability:

[3] Billy Vaughn Koen: Discussion of the Method, 2003,

[4] Robert C. Martin: The Principles of Object-Oriented Design, 2005,

[5] Dan North: Why Every Element of SOLID is Wrong, 2017,

[6] Charles Petzold: The Annotated Turing, 2008,

[7] Gerald M. Weinberg: The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, 1986,

[8] Donald C. Gause, Gerald M. Weinberg: Are Your Lights On? How to Figure Out What the Problem Really Is, 1990,

Added 03/21/2021:

[9] Dan North: CUPID – the back story, 2021,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s