Blink squinted at the diagram, full of tiny boxes and arrows and a color key that looked like one of those giant boxes of crayons he used to have when he was in kindergarten. Something about it seemed familiar, he just--
"Wait, we built something just like this 2 years ago, didn't we? The Burrito."
The Architect looked exasperated.
"No, Blink. This is a Crunchwrap™️. It has a tortilla, meat, cheese, and sauce."
Blink... blinked. (Ha, get it? 😏)
"What's changed?"
The Architect's exasperation grew, if that was even possible. He was very nearly literally beside himself.
"That was completely different. Tortilla, meat, sauce, and cheese. Honestly, Blink: some of us are building the future while you're over there ordering off the Value Menu."
Idea Laundering
Most of what we call "Architecting" looks a lot like Taco Bell: same core ingredients, rearranged to be "new menu items". Don't believe me?
Ingredients
- Compute
- Storage
- Network
- Data Structures
Menu Items
- Microservices
- Serverless
- Event-driven
- “Platforms”
- "Agentic"
It's right there in front of you. Instead of inventing new ingredients, we're just endlessly recombining... folding the same ones differently and calling it innovation.
And That's Not a Bad Thing™️
Sometimes, recombination is a valuable step. It makes us evaluate whether things are needed in large quantities or small (or perhaps whether they're needed at all). It makes us "improve the packaging"... are we being judicious in our delivery? Sometimes the context of the business changes, and what used to work doesn't anymore.
To return to the analogy briefly, Taco Bell isn’t scamming you with the recombination process. It’s efficient. It’s scalable. It feeds a lot of people while keeping prices down.
And that's the story of most companies with their IT Departments. They aren't supposed to be inventing new ingredients, they're supposed to be delivering what their business needs them to do.
It Can Create Problems, Though
Taco Stand engineering becomes problematic when we allow it to distract us. Think about the "recombination" activities that occur in typical software development:
- Endless redesigns
- Renaming things to fit the latest Leadership Framework
- Debating patterns and processes
- Re-platforming for marginal gains
- Chasing a Hype Cycle instead of addressing Business Value
We technologists are arguing about whether it’s a burrito or a Crunchwrap AND NOT REALIZING THAT THE KITCHEN IS ON FIRE.
The Billowing Smoke We Ignore
We'll have multiple design meetings to build out a better architecture diagram, or redefine service boundaries, or implement a new framework, or pontificate on "the right pattern"... but across the aisle, our development team contends with slow CI/CD pipelines, flaky tests, unclear ownership, poor observability, contentious and/or brittle local dev environments, and unreliable deployments.
Your diagram's arrows aligning with the box corners aren't going to make your bottom line go up by one penny... but that's where the time and attention gets spent, instead of fighting for a better Developer Experience.
In Taco Bell terms, your burrito isn't failing because of how it got folded. It's failing because you filled it with junk, but spent all your time and effort worrying about the folds.
Imagine for example a huge effort to turn a monolith into 50 microservices. If you don't fix the fundamental problems, you'll just end up with 50 slow builds instead of 1.
Better is Possible
A good architect isn't afraid to ignore the menu and remodel the kitchen sometimes.
What does that mean?
Faster feedback loops. Don't spend an ounce of energy building something that isn't the highest priority... which means you have to know what that highest priority IS... ALL THE TIME.
Reliable tests. You can only deliver as fast as you can validate. Your test suite is your very best friend. (interesting lesson here for you Agentic whiz-kids... the speed of writing code isn't as important as the speed of testing code...)
Clear interfaces. Boundaries should be well-defined, people should know what they're responsible for and what they're not.
Great developer experience. Do you want to spend your development cycles overcoming friction, or delivering value?
Making new menu items out of old ingredients isn't "improvement", it's "novelty". Making better ingredients means that every single menu item improves at once.
(Crunch)Wrapping it Up
A while back, we examined The Fundamentals... today, I want to leave you with a more pointed summary in the same vein:
Stop redesigning the menu. Go fix the kitchen.
Top comments (0)