So many fallacies
Bronislav Klučka on Mar 05, 2025
Have you ever wondered...
Some people think dependency injection should be used everywhere and is the latest technology. Similarly, some people think layered architecture is the best approach for everything, while others feel the same way about microservices.
Some people think that serverless is always the way to go. Others think that everything has to be written in Rust on the back end and Vue 3 on the front end.
Some people think that if you make one person a product owner and another a scrum master, send them both on a two-day certification course, and have them do standups, reviews, and retrospectives, and use Jira, then you are an agile team doing scrum.
Have you ever wondered...
These things all have one thing in common: a lack of understanding of values and principles.
The pyramid
How do you make decisions? What influences your decisions? What makes some behaviors coherent and others incoherent?
Values
Values represent your core beliefs. What you do is filtered through these values, determining whether it is a "go" or a "no-go." Values are the most important and desirable attributes that define how you work and who you are. They are the motivation behind everything.
Values are the answer to the question, "Why do you do what you do?"
Principles
Principles are basic rules and behavioral guidelines supported by values. They are truths about almost every aspect of your daily behavior. Every practical action you take involves these principles.
Practices
These are your daily behaviors and operations.
Tools
Tools are what you use for your daily operations.
Tools must fit practices, which must be based on principles that reflect values.
Cargo cult
In my opinion, cargo cults are the most widespread and dangerous. The term comes from the behavior of Pacific Islander tribes and communities during WWII. During the war, the U.S. Army created bases on Pacific islands, and the indigenous population saw people wearing headphones and waving flags in the air. Then, cargo arrived by airplane.
After the U.S. Army left, the natives started wearing coconuts on their ears, waving cloth in the sky, and building landing strips. They didn't understand what was going on, why the people before them wore those things, or why the cargo came. They hoped that by mimicking the behavior, they would get the same result - cargo.
How many behaviors are driven by imitation? We see someone doing something, read about it somewhere, or hear about it from someone, and we imitate the behavior without understanding the values and principles behind it. Without understanding the basic why and how.
Golden Hammer
The term golden hammer describes the overuse of a specific tool or process to solve all problems.
Should we use a Vue-based SPA for everything? Should we? Why?
Should we use a layered architecture for the backend? Really? Why? Why did you choose this style over another? Is it because you have a reason, or because you're used to it?
The worst thing I can hear from developers is, "I've been doing it this way for 20 years." All that tells me is that they haven't learned anything in two decades.
Silver bullet
The term silver bullet describes the wishful thinking that there is a simple solution to complex problems. There may be one, but not because you want there to be.
We need more customers. Let's release more shiny buttons! But there's no correlation between the number of features and success. Have you noticed how simple Netflix and Gmail are?
We need better software. We need to hire better developers. Maybe. Maybe not. Have you really looked into the reasons why? Is it all the developers' fault?
We need better software. We need to hire a better product manager or owner. This one is pushing the developers too hard. Maybe or maybe not.
Commercial software engineering is a complex discipline. There is no magic solution to turn bad into good.
More examples?
How about one technical and one organizational?
Dependency injection
DI exists to solve a specific problem: to provide functionality without the consumer knowing where it comes from or what provides it. For example, consider application-wide logging. Some random function or class should not know how logging works or where the "logger" comes from. All it needs to know is that there's an interface that provides logging functionality.
How is DI often used? We have a program module that handles users, for example. We build the controller, service, repository, and model outside of this module in an application-level container and pass everything top-down. My question is, why? Why should the application know how the user module works internally? Why is there one container for the entire application? Why is the definition of "DI" for the user module located next to the billing module's definition? What do these modules have to do with each other? Shouldn't the user module be responsible for how it works without revealing that information to the outside? Shouldn't the user service know exactly what kind of repository it needs? Why do we pass classes instead of the minimal interface possible? Why do we pass the DI to the constructor when only one method uses the functionality?
Why? Because "everyone does it that way."
Scrum
Agile software development has become fashionable. It has become a product sold by consultants who have never actually managed a project and a brand worn by companies to show how modern and dynamic they are. So, how do we do Scrum? Management defines priorities ("customers are stupid; we don't talk to them"), timeframes ("developers are stupid and don't understand business"), and the way of working ("testing is a waste of time"). Developers are lucky if they can define a scope that fits into a sprint occasionally, and customers are lucky if the product manager (or whoever) in the ivory tower considers their needs.
Why is Scrum used? Because it's the easiest way for a company to pretend it's using an agile framework.
What about the values or principles of agile software development? When was the last time anyone read them?