I spent years as a consultant walking into other companies' engineering teams and culture. Twenty-some companies, twenty cultures, twenty different ways of building software, and something like 500 repositories along the way. Every single one of those teams had its beliefs. And sooner or later, every conversation hit the same wall: "no, here we do it this way."
This post is about that wall. About dogmatism in software development, why it exists, why it's actually useful, and how to notice when it stops serving you.
Rules are compressed experience
A dogma is a principle laid down by an authority as an incontrovertible truth. Sounds bad when you put it like that, but rules and best practices exist for a good reason: they're a compact way to transmit what a group of people learned in a particular situation. Someone tested the paths, most failed, one worked, and the result got compressed into a rule so the next person doesn't have to rediscover everything from scratch.
Beginners genuinely need this. If you've read about the Dreyfus model of skill acquisition, that's the novice stage: you follow context-free rules because you don't yet have the judgment to know when they apply. That's fine. That's how we all learned.
The problem starts when the rule outlives the context that created it. Best practices become dogmas, and nobody notices, because the rule keeps being repeated with full confidence long after anyone remembers why.
Every hot take has a counter-take
Take any of the practices we argue about. Do we practice TDD at my company? Yes. Do we practice it 100% of the time? No. Some people more, some less, some problems fit it, some don't, and none of that makes anyone a good or bad engineer.
Pair programming has real benefits, and some people will tell you, with acid certainty, that it is how software gets made. Fine, but are there other ways to get those same benefits? Microservices went through the same cycle: for a while it was "this is how software is built now", with distributed systems, isolated responsibilities, teams working independently. And a loud counter-camp saying "this is madness, don't".
My favorite: continuous integration. I'll risk a big claim here, the same one I made on a conference stage years ago: most of you don't do continuous integration. I discovered I didn't either. I went and read what CI actually requires, integrating to trunk daily, and realized my feature-branch workflow didn't qualify. I removed it from my LinkedIn. It was a bit of a shock, honestly :)
"We don't use X here"
I had my own dogma, and I used to state it exactly that badly: "we don't use Sinatra" (a minimalist web framework, for those outside the Ruby world). That phrasing carries none of the experience behind it.
The honest version takes longer: "in the kind of projects I work on, starting with a minimal framework tends to backfire, because the scope always grows, you slowly rebuild the full framework around it, and you'd have saved time starting with the batteries-included one." That's a real lesson, learned across real projects.
Then a friend of mine says: "I use Sinatra in my courses." Is he wrong? Not at all. He's teaching HTTP and APIs, and a minimal framework is perfect for that. Different context, different right answer. My rule was fine. My rule stated without context was not.
Two things follow. First, always ask where your rule applies and where it doesn't. Second, rules have an expiration date. My Sinatra experience was years old even when I was repeating it, and the tool could have changed under me. Beliefs need re-validation, and we almost never go back and re-test them.
How to detect a dogma
A few phrases work as reliable detectors, in others and in yourself:
"It's always been like this." "It's always worked this way." And my favorite: "so-and-so said so."
The appeal to authority deserves its own paragraph, because we do it by accident. Martin Fowler is a great example, through no fault of his own. He compiles and explains practically everything in our field, and he's careful about it: in the classic mocks-versus-stubs article he states his own preference and lays out the trade-offs of the other side. Then we grab the conclusion, strip the context, and deploy it in our own world as "Fowler said". Fowler is far away. He's not in your standup, he doesn't know your codebase, and he was careful to give context precisely so you wouldn't do that.
A phrase I stole from a friend: don't have idols, have references. The people at the top of our field are excellent, and they're also regular people who make regrettable choices and take awkward photos. Respect them, read them, and don't outsource your judgment to them. Which is an ironic thing to say from a blog post, so: don't take me too seriously either.
"Let's just discuss it as a team"
At this point the obvious fix appears: we're an agile team, we'll discuss our practices openly and reach a consensus. Beautiful. Does it work?
Social psychology has bad news. The first result: group polarization. Discussion inside a group tends to amplify the average prior opinion of its members. If the team already leaned toward adopting the shiny new technology, after the meeting it leans harder. If it leaned against, it leans harder against. The discussion didn't evaluate the question, it exacerbated the starting position. This result has been replicated across countries, ages, and settings.
Then Irving Janis asked the next question: surely structured, high-stakes environments, military command, presidential cabinets, have mechanisms to counter this? He studied them and found the opposite, and coined the term groupthink for what he saw: group pressure that cancels the appraisal of alternatives and produces, in his words, a deterioration of mental efficiency, reality testing, and moral judgment. When I first read that sentence I thought: I never want this near my team. And then: this is my team, this is every software team, we make group decisions all day.
Janis catalogued the symptoms in three families, and you will recognize some:
Overestimating the group. The group's decisions feel invulnerable and its morality unquestionable. If we're all heading this way, it must be the right way.
Closed-mindedness. Outsiders with contrary opinions get stereotyped away ("he's a beginner, he doesn't know our reality"). Warnings get rationalized instead of checked. His example is Pearl Harbor: the warnings existed, and the command explained each one away ("last month there was a scare too, and it was nothing") instead of sending a single plane to go look.
Pressure toward uniformity. Self-censorship: you disagree, but everyone else is more experienced, so you stay quiet. Which produces the illusion of unanimity: did everyone agree, or did they nod in silence? And my favorite, mind guards: members who filter inconvenient information before it ever reaches the group, sometimes with the best intentions, to protect the team from "stress".
Janis also catalogued the conditions that produce all this (a cohesive, isolated team with homogeneous backgrounds and no impartial leadership) and a prevention playbook: examine the alternatives for real, split into independent groups, bring outsiders in, rotate a devil's advocate. I won't go deep on those here. The part I want you to carry from this post is the symptoms, because detection comes first: you can't fix a dysfunction the group is structurally unable to see. Watch for the nodding silence. Ask yourself if you've ever been the mind guard.
The duty of context
One last thing, and I think it's the most important one. When someone newer asks you "should I use A or B?", you have a moral obligation to not answer with a verdict. "Use A" is how dogmas reproduce. The honest answer includes the context: what you tried, where your experience comes from, what was different about your situation. It takes longer. It's worth more. And there's a bonus: explaining your rule out loud forces you to re-evaluate it, and sometimes you catch one that expired while you weren't looking.
Everyone is a novice in some area of knowledge. You'll be on the other side of that question soon enough, hoping someone gives you the context instead of the verdict.
So keep your rules. They're compressed experience, and they got you here. Just check the expiration date once in a while.
Or, as Peter Ustinov put it: "Beliefs are what divide people. Doubt unites them."