"Best Practices" at best lead to average results: "The Context Paradox"
If you want to trigger me, please drop a "we should follow best practices!" without much context. In case this isn't evident - if everyone follows the same practices, and these practices are "best," why do we see such wildly different outcomes? Here's the thing: best practices optimize for the average case. And your system? Your team? Your challenges? They're anything but average (hopefully…).
The Mannequin Problem
Picture this: you're shopping online, and that shirt looks absolutely perfect on the model. Perfect fit, umphfy™, perfect everything. Then it arrives, it looks like it should, this time you haven't been cheated by random seller, then you try it on, go to the mirror … and then it hits you like a ton of bricks … fits like crap 💩, torso is too tight, arms are loose and your whole enthusiasm comes crumbling down … sucks right? Did the seller want to bamboozle you? Not really, it is just not made for you (body type) … The seller / maker of the shirt had a different audience / body type in mind.
This is exactly what happens when we blindly adopt architectural patterns or any management / leadership model blindly. They look fantastic in conference talks, pristine in blog posts, demonstrated on example applications with conveniently simple requirements. Your system isn't a conference demo. Your team isn't the one that wrote that Medium article. Your constraints? Completely different.
When Good Practices Go Rogue
Picture an internal expense tracking system. Maximum concurrent users? Maybe 50 on that dreaded Monday morning. Total user base? 300 employees who'd rather get a root canal than file another expense report.
Now imagine their architecture: seventeen microservices (because modularity!), three different message queues (because decoupling!), and a deployment pipeline that would make NASA engineers jealous. Each expense approval touches seven services. A simple receipt upload becomes a distributed transaction saga worthy of a Viking epic.
Why would anyone do this? Oh, you know why. Because that's what the "best practices" say. That's what FAANG does. That's what gets you those sweet, sweet nods of approval in architecture reviews. "Look how scalable we are!" … for our 50 users … who mostly work 9-to-5 … and take the same lunch break …
Here's the kicker - Netflix has over 200 million subscribers streaming 4K video while you're binge-watching at 2 AM. Their challenges? You'll never have them. Hell, you probably don't want them. When you copy their solutions, you're not just importing their patterns … you're importing their problems. Congratulations, you played yourself.
The Context Spectrum
Think about two different systems. First up: a high-frequency trading platform. Millions of transactions per second, each one potentially worth millions. Every trade must be captured, immutably, forever. Audit trails aren't nice-to-have; they're "go to jail if you mess this up" required. Event sourcing? Makes perfect sense. The complexity pays for itself in compliance officers' peace of mind.
Now, let's visit our friends at Joe's Pizza Chain™. Someone (let's call them "Architecture Andy") reads about event sourcing. Gets excited. Really excited. Implements it for … table reservations.
Suddenly, canceling table 5 isn't just UPDATE reservations SET status = 'cancelled'. Oh no, that would be too simple. Now it's an event! That needs processing! And projecting! And eventual consistency! The kitchen staff is googling "what is eventual consistency" while customers are wondering why canceling a table takes longer than making the actual pizza.
Same pattern. Same "best practice." Wildly different contexts. One makes millions, one makes ... confusion.
Products vs Internal Tools: A Tale of Two Worlds
Product development is like sailing into a storm you ordered on Amazon - you know it's coming, but you have no idea how bad it'll get. Will you have 10 users or 10 million? Which features will actually matter? You're basically throwing spaghetti at the wall and praying something sticks (and that it's monetizable).
Internal applications? That's like driving to work on the same route you've taken for five years. Your users? They're Dave from accounting and Sarah from HR. Peak load? Monday morning when everyone remembers they have expense reports due. The biggest surge? End-of-quarter when finance suddenly remembers they need those reports.
Yet here we are, watching internal tools built like they're preparing for their IPO. Kubernetes clusters orchestrating containers for an app with the user load of a neighborhood lemonade stand. Elaborate caching layers for data that updates when Mercury is in retrograde (quarterly, if we're being honest). Auto-scaling groups for services that could run on that laptop you forgot about from you third drawer.
Meanwhile, three buildings over, product teams are crying into their monoliths because they followed the "start simple" mantra a bit too religiously. Now they're duct-taping servers together because some blog said "premature optimization is the root of all evil." Context got flipped, and everyone's too busy in sprint planning to notice.
The Averaging Problem
Best practices emerge from successful projects. Sounds legit, right? Here's the catch - when you blend approaches from startups and enterprises, from "move fast and break things" cultures and "one bug could literally kill someone" industries, from B2C apps and internal tools, what emerges isn't some uber-practice.
It's like creating the ultimate recipe by mixing Thai curry, Italian carbonara, and Texas BBQ. You know what you get? Something that would make Gordon Ramsay weep … and question his life choices.
These averaged practices smooth out all the interesting bits - the specific constraints that made certain decisions brilliant for certain teams at certain moments. The context that made them "best" gets lost faster than your motivation on a Monday morning.
Questions Over Answers
So what's the alternative to cargo-culting best practices? Start with questions. Good ones. The uncomfortable ones.
When Architecture Andy proposes the Latest Pattern™, resist asking "is this a best practice?" Try these instead: What problem does this actually solve? Do we have that problem? Like, really have it, or are we just bored? Will we have it at our scale? (Spoiler: your internal app isn't going to become the next Facebook.) What does this pattern assume about team size, system load, change frequency? Do those assumptions match our reality, or are we living in Architecture Andy's fantasy land?
Consider the cost of being wrong. If we don't need this complexity now, how painful is it to add later? If we do need it and don't have it, what actually breaks? Sometimes the answer is "nothing important," and that's when things get interesting.
The Boring Advantage
Here's something that won't get you invited to speak at conferences: boring can be beautiful. That single VM running your internal tool? If it works, it works. That monolithic application that your developers actually understand? Maybe it doesn't need to be atomized into microservices just because Twitter said so.
I know a SaaS company still running as a monolith. One. Big. App. The horror! Except … they're profitable. Their developers can trace through code without needing a distributed systems PhD. They deploy without sacrificing goats to the Kubernetes gods. They chose boring, and boring chose them back (with interest).
There's this financial services firm running technology so "legacy" it probably remembers when COBOL was the hot new thing. Tech Twitter would have an aneurysm. But guess what? Their uptime is measured in years. Not five nines. Years. Their customers trust them with billions because the system Just. Keeps. Working.
These aren't failures to modernize. They're successes in understanding what actually matters. Revenue? Check. Happy customers? Check. Developers who sleep at night? Check. Bleeding-edge architecture? … Who cares?
Your Constraints Are Your Superpower
The enterprise can't match your startup's ability to completely rewrite everything over a long weekend fueled by energy drinks and questionable life choices. The startup can't match your enterprise's ability to throw money at problems until they surrender. Different contexts, different superpowers.
When you embrace your context instead of fighting it, you act like a grown-up. You can be simpler where others are drowning in complexity. You can move faster where others need seventeen approval meetings. You can optimize for what actually matters to YOUR users, not what mattered to someone at a conference in 2019.
The Almost-Right Trap
Here's the sneaky one - watch out for practices that are almost right for your situation. These are the dangerous ones. They're close enough that you don't question them deeply, different enough that they slowly poison your architecture like that leftover sushi you're eyeing suspiciously.
You know the feeling. Every feature feels like you're arm-wrestling your own architecture. Simple changes require complex ceremonies that would make the Vatican jealous. Your patterns feel like they're actively sabotaging you. That's usually your context trying to tell you something … if you'd just listen.
Finding Your Own Way
Excellence doesn't come from copy-pasting someone else's homework. It comes from understanding your own assignment. Your users (all twelve of them, or twelve million). Your constraints (budget, time, or sanity - pick two). Your capabilities (what your team actually knows, not what they claim on LinkedIn).
Best practices can spark ideas, but they shouldn't replace thinking. That's like using GPS to navigate your own living room. Technically possible, but … why?
Next time someone drops "best practice" in a design review, take a breath. Count to three. Then ask: "Best for whom? In what context? Under what constraints?" Watch the gears turn. Enjoy the silence.
The Unaccountability Machine
You know what Dan Davies would say about all this? In "The Unaccountability Machine," he nails how organizations create elaborate systems to avoid making actual decisions. Sound familiar? "We're just following best practices" is the architectural equivalent of "I was just following orders."
These practices become a shield. Can't blame me for the over-engineered mess - I followed the Netflix architecture! Can't fault our choices - we used industry best practices! It's accountability theater. We hide behind the complexity we created, pointing at conference talks and blog posts when things go sideways.
The real accountability? Understanding YOUR context, making YOUR choices, owning YOUR decisions. Even if they're "wrong" by some arbitrary standard. At least they're yours.
Architect's Alert 🚨
Here's the trap that catches even experienced architects: best practices become dogma. They start as "this worked well in this context" and mutate into "thou shalt always do this or face the wrath of the architecture review board."
The moment you hear yourself saying "but that's not how Google/Netflix/Amazon does it" - stop. Full stop. You're not Google. Your problems aren't their problems. Their solutions might actually be poison for your system.
Watch for these warning signs:
Every simple feature requires a design document longer than the code
Your architecture diagrams look like modern art (and are about as understandable)
New developers need a PhD in distributed systems to add a button
You're solving problems you'll never have while ignoring the ones staring you in the face
The real skill? Knowing when to break the rules. The best architects I know have a healthy disrespect for "best practices" and an unhealthy obsession with understanding their actual context.
The Path Forward
Think about your current project. Really think about it. What "best practices" are you following that feel like wearing someone else's prescription glasses? What unconventional choices might actually serve you better? What would happen if you optimized for YOUR context instead of some mythical average?
Remember: the most interesting architectures aren't the ones that follow all the rules. They're the ones that know which rules to break, when to break them, and why breaking them makes sense … for them.
Your context is unique. Your challenges are specific. Your solutions should be too.
Now go forth and build something that fits YOU. The conference speakers can wait.