IT problems are not random: they follow the same principles
After a few years in the workplace—especially in IT—if you’re a curious person who pays attention to what’s happening around you, you start to notice something strange: different problems, different companies… but the same dynamics.
That’s not a coincidence.
As someone who’s always been fascinated by recurring patterns, I’ve tried to abstract these situations and, over time, map them onto other contexts. What surprised me the most is how perfectly the mapping worked: similar situations, different actors, same outcome.
Driven by curiosity—and by the feeling that I couldn’t be the only one noticing these patterns—I started digging deeper. I read, researched, and looked for others who had experienced or at least observed the same dynamics. And that’s when I discovered a whole world of “unwritten laws” that describe these phenomena remarkably well and try to explain why they happen.
So, partly for fun, I decided to share them in this article. It might be interesting for other curious people who try to extract behavioral patterns from situations they’ve experienced.
I’ve collected a set of “unwritten laws” that attempt to explain why certain things keep happening. Some relate to code, others to people… and more often than not, the problem is the latter.
To give this some structure, I grouped them into four categories that, at least to me, make sense:
- Laws of code (or technical laws)
- Laws of abstraction and complexity
- Laws of people
- Laws of chaos
Below is a selection of the ones I’ve encountered most directly (fully aware that there are many more out there).
Laws of Code
Linus’s Law (≥ 1997)
“Given enough eyeballs, all bugs are shallow.”
📖 Source: The Cathedral and the Bazaar – Eric S. Raymond
http://www.catb.org/~esr/writings/cathedral-bazaar/
This is one of those statements that sounds almost trivial at first… until you actually experience it.
In theory: the more people look at the code, the higher the chances of finding issues.
In practice: the bug you’ve been struggling with for days… gets spotted in 30 seconds by someone else.
How many times has this happened?
Hours staring at the same piece of code. Debugging, logs, attempts, hypotheses.
Then someone walks in, looks at the screen, and says:
“Wait… there’s a missing check here.”
That’s it.
And that’s the moment you realize how paradoxical it is: it was right there in front of you the whole time, and you just couldn’t see it.
And you understand that the problem wasn’t complexity… it was simply the number of eyes.
Law of Leaky Abstractions (2002)
“All non-trivial abstractions, to some degree, are leaky.”
📖 Source: Joel Spolsky
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
This is one of the truest laws out there—one that, sooner or later, everyone runs into.
Especially when working with frameworks, libraries, or PaaS platforms.
Abstractions exist to simplify things: they promise you don’t need to know what’s happening underneath.
And it works. Until it doesn’t.
Then something changes:
- performance starts to degrade
- something breaks
- the behavior is no longer what you expect
- you try to push the framework with logic you know is possible… but isn’t exposed
At that point, you have no choice: you have to dig deeper.
And that’s when the real realization hits:
you were using something you never truly understood… or at least, not deeply enough.
Abstractions don’t remove complexity.
They hide it… until it comes back to find you.
Hyrum’s Law (≥ 2014)
“With a sufficient number of users, all observable behaviors will be depended on by somebody.”
📖 Source: https://www.hyrumslaw.com/
This one is subtle… but devastating.
You can document an API as much as you want.
You can clearly define what is supported and what isn’t.
It doesn’t matter.
If a behavior exists—even if it’s not documented—someone will rely on it.
And the moment you try to change it… something will break.
Even if, technically, it was never supposed to work that way.
That’s when you realize something fundamental:
users don’t just rely on what you document.
They rely on everything they observe.
Which means that, in production, nothing is truly “internal.”
Every exposed detail becomes a promise—even if you never intended it to be.
Laws of Abstraction and Complexity
If the previous ones explain the code, these explain why code, over time, becomes hard to manage.
Hofstadter’s Law
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
📖 Source: Douglas Hofstadter, Gödel, Escher, Bach
🔗 Wikipedia – Hofstadter’s Law
At first, you think you’re good at estimating.
Then you realize you’re just getting better at guessing.
Because:
- you don’t know all the variables
- you underestimate the details
- you overestimate how linear things will be
And even when you factor in the fact that you’ll be wrong…
you’re still wrong.
Maybe the real goal isn’t to be perfectly accurate, but to be wrong as little as possible—or to build enough contingency to absorb the gap.
Brooks’s Law
“Adding manpower to a late software project makes it later.”
📖 Source: Frederick P. Brooks – The Mythical Man-Month
🔗Wikipedia – Brooks’s Law
This one is counterintuitive—until you actually experience it.
It was one of the first real lessons I learned: an important client, a project already heavily delayed, endless extra hours that stopped being tracked, and a project manager introducing new people to the team every single week.
When a project is in trouble, the natural reaction is: “let’s add more people.”
But more people means:
- more communication
- more alignment
- more context to transfer
And the people already working on it… what do they do?
They slow down to onboard everyone else.
That’s when it becomes frustrating: those who have been carrying the weight for months suddenly find themselves training people who need time to ramp up, who have questions, and who, inevitably, are not yet productive.
Only those who have lived through this know it:
you don’t fix emergencies—you prevent them.
You prepare people before a project reaches a critical state.
And, realistically, only those who have those scars should be the ones managing projects or taking on leadership roles.
Laws of People
This is the part that has always fascinated me the most.
It’s also where, over time, I’ve seen the strangest things—and where I believe the real problems begin.
Because code is complex, but it’s (or at least should be) deterministic.
People, on the other hand, are much more unpredictable.
The Peter Principle
“People are promoted to their level of incompetence.”
📖 Source: Laurence J. Peter – The Peter Principle
🔗 Wikipedia – Peter Principle
At first, it sounds cynical. Then you start to recognize it.
The best developer becomes a team lead.
Over time, the team lead becomes a manager.
And at some point… they’re no longer in the right role.
They’re moved away from what they were great at and into a position where they no longer bring the same kind of value.
The perspective shifts completely:
before, they were the most experienced person in the room—the one others relied on.
Now, they’re the one who needs to learn.
In an instant, you go from senior to junior.
Because, as is often the case, value depends on the perspective from which you look at things.
And for many (not all, of course), that’s where things stall: they end up in a kind of limbo, where growth slows down or stops.
Not because they’re not capable, but because the role is different.
The Dilbert Principle
“Companies tend to move their least competent employees into management.”
📖 Source: Scott Adams – The Dilbert Principle
🔗Wikipedia – Dilbert Principle
This is where the tone shifts.
It’s no longer a side effect—it almost feels like a strategy.
People who create operational problems get moved away from operations… and often end up making decisions.
In my early years, I used to watch this with disbelief.
We’d talk about it with colleagues by the coffee machine, saying things like:
“Did you see the guy who caused that build break?
Completely messed up that design, delayed the whole project… and got promoted?
Now he’s the technical lead on a new project?”
Then, over time, you start to understand.
You lose that initial naivety and realize that the promotion isn’t random—it’s intentional.
You’ve simply moved a problem to another level… and walked away from it in an elegant way.
Masters of the game.
The Gervais Principle
“It’s not the most competent who wins. It’s the one who understands the game.”
📖 Source: Venkatesh Rao
https://www.ribbonfarm.com/the-gervais-principle/
This is probably the most uncomfortable one. Being competent is not enough.
What often makes the difference is understanding how the organization actually works.
Companies are not purely meritocratic systems.
In most cases, they resemble complex social systems.
And like in any social system, those who understand the dynamics of:
- relationships
- perception
- power
have a real advantage.
How often does a highly skilled engineer remain stuck in the same role, while someone who navigates the environment better moves forward faster?
Probably more often than we’d like to admit.
Laws of Chaos
And finally, the ones that close the loop.
Because there’s always that unpredictable thread connecting everything.
Because even when everything seems perfect…
it isn’t.
Murphy’s Law
“If something can go wrong, it will.”
📖 Source: Murphy’s Law (attributed to Edward A. Murphy Jr.)
🔗 Wikipedia – Murphy’s Law
t’s not pessimism. It’s statistics applied to reality.
In IT, it means:
- it works locally
- it works in testing
- it breaks in production
Always at the worst possible moment.
Always with the most critical client.
Always on a Friday… or right before a day off (or a vacation) you’ve earned the hard way. 🙂
Hanlon’s Razor
“Never attribute to malice that which is adequately explained by incompetence.”
📖 Source: https://en.wikipedia.org/wiki/Hanlon%27s_razor
This is an almost liberating realization.
How many times have we found ourselves facing absurd problems, situations that feel almost unbelievable? Issues so obvious that they make you question whether there was bad intent behind them.
But the reality is different.
Most problems:
- are not sabotage
- are not driven by malice
they’re simply mistakes.
They’re simply incompetence from people who are in roles they’re not fully capable of handling.
It’s not about bad intentions or willingness—it’s just incompetence.
And once you understand that, it completely changes how you react.
Final Thoughts
There are so many of these principles and patterns that listing them all would require a book.
Here, I’ve collected the ones I’ve encountered most often—because after a while, you start seeing them everywhere.
Different projects.
Different companies.
Different people.
Same dynamics.
And maybe the real skill isn’t avoiding them—because in many cases, you can’t—but recognizing them before others do.
Because at that point, you’re no longer just reacting to problems.
You’re anticipating the patterns.