NoSQL

If you have enough money, you can convince anyone of anything. I remember when the first whispers of NoSQL started circulating. They kept getting louder. Eventually, I began running into MongoDB advocates preaching that "schemaless is the future."

Companies rushed to adopt it, started paying millions in support, and began creating clusters and shards. People started writing books on how to do big data and analytics using NoSQL technologies. All the cloud providers jumped on board with their own NoSQL offerings.

The reason as to why not to use NoSQL merits its own paper, as it would be a technical dive into how the masterpiece or a relational database like MSSQL or SAP ASE works and what it can do you for. I have not the strength for it now in this context.

The result of the experiment?
Absolutely useless technology with no reason to exist. You can do everything you need with a relational database. Every project I’ve joined that uses MongoDB is a total mess—mostly because the folks who got suckered into using it also adopted a bunch of correlated technical cancers (more on that below).

SPAs

At first, I thought React was magic. I told myself, "This is the future! Look Mom, I’m coding! Weee!"

Everyone kind of had the same internal monologue when create-react-app launched. Server-side rendering was suddenly uncool. Everyone wanted to spin up SPAs—whether with React, Vue, or Angular.

I built many of them and had a blast. But over time, I started noticing things:

  • My frontend router ballooned in size
  • New state management patterns seemed to pop up weekly
  • Debugging became harder since URLs no longer matched data-fetching endpoints
  • Component trees exploded, props were passed around like candy, and managing cross-component state became a nightmare

I had to maintain a second deployment pipeline just for the frontend and coordinate deploys with the backend.

After many SPAs—built from scratch or inherited—I noticed a pattern: all of them resulted in massive JavaScript repos. Whatever happened to the UI being a thin layer?

SPAs, by nature, lead you down a path of unnecessary complexity. Things got even weirder after create-react-app was abandoned. Opinionated React frameworks like Next.js took a hard left into a direction that no longer reflects practical development.

We’ve since gone back to server-side rendered apps. No frontend routing. State is managed on the backend.

ORM

I was one of those Ruby on Rails enthusiasts back when it was on top. I had a strong grasp of the framework and could churn out web apps quickly (they were all garbage, by the way).

One of the key features in Rails—and most MVC frameworks—was ORM: Object-Relational Mapping. You define a class in your app layer that maps to a table. Each class instance is a row; attributes are columns. Magic, right?

It’s a cool trick to impress folks at a bootcamp or when you’re first learning to code. But it absolutely does not scale to enterprise systems.

ORMs have no concept of OLTP (Online Transaction Processing). They bypass stored procedures, views—the real database interface—out of the hubris that you can just manipulate tables via your model layer.

I’ve worked on large Rails apps at major companies. Half your brainpower is spent performing mental gymnastics to get the ORM to behave. Some objects make dozens of network calls on instantiation. Others fetch nested associations in hilariously inefficient ways. Debugging becomes a black hole of inheritance and indirection.

Microservices

Folks who swear by microservices clearly never watched Dragon Ball Z. There’s an amazing dialogue between Piccolo and Android 17. 17 is confident he’ll win because he has unlimited energy. He smugly tells Piccolo he’ll eventually get tired. But Piccolo calmly replies:
“You’re not perfect. You’ll make a mistake before that happens.”

That line has stuck with me. It sums up my feelings about microservices.

The architecture sounds powerful on paper—modular, decoupled, scalable. But in practice, it just increases the number of places where mistakes can happen. Every time I’ve worked on a microservices-based system, I’ve seen the same thing: complexity through fragmentation. You’re no longer working in one codebase—you’re juggling a dozen. You’re chasing logs across multiple services, dealing with subtle integration bugs, and managing cross-service state and network failures.

Microservices require massive organizational discipline and maturity. But the teams that usually go all-in on microservices? Ironically, they’re not the ones equipped to handle that kind of operational burden. They just read the same blog posts and wanted to be like Netflix.

This is by no means an exhaustive list just what I had on my mind on a given saturday. Look out for the next in my All is meme series