Looking back, most of the architecture mistakes I’ve made came from trying too hard to make things “right” — whatever that meant at the time.
I would spend hours thinking through abstractions, layering things just-so, imagining how the system might evolve in the future. It felt like good engineering. And to be fair, some of it was. But a lot of it was just guessing. Or worse, overfitting to a future that never came.
Eventually, I learned a principle that I now use in almost every system I touch:
Design for change. Not permanence.
This might sound obvious, but it’s not how most systems are built. There’s this quiet pressure — especially on more senior devs — to build “future-proof” systems. Something that scales. Something that’s generic enough to handle unknown requirements. Something modular and layered and clean.
The problem is, most of that work is based on predictions. And predictions are often wrong.
What helped me more was to stop thinking in terms of “is this the right abstraction?” and start asking “how painful will it be to change this later?” The goal shifted from stability to flexibility.
Here are a few things that changed in my approach:
- I stopped trying to predict the future. Instead of building the perfect abstraction upfront, I’d build the version I could explain clearly to someone else on the team. If we needed to change it, we’d refactor with context instead of guessing ahead of time.
- I started caring more about the edges. Where things break. Where things integrate. A lot of architecture isn’t about internal purity — it’s about making sure the parts that change often don’t bring everything else down with them.
- I gave up on cleverness. If I needed a long comment to explain how two components interacted, that was a red flag. I learned to optimize for readability and traceability over theoretical correctness.
None of this means you shouldn’t think things through. It just means it’s okay to build something plain and clear, even if it’s not “elegant” in the academic sense. Most production systems aren’t elegant. They’re just coherent enough to change safely.
I still think about design. But now I think about it more like scaffolding — useful, but temporary. Something you might remove or reshape as the real structure takes form.
The architectures I trust most now are the ones that don’t mind being rewritten. Ones that can grow without falling apart. Ones where you can change a piece without re-learning everything else.
That’s what I aim for. Not perfection. Just something that can move with the team.