How Not to Architect
Today at a Glance
Poll of the Day
Where would you prefer to read my content?
How Not to Architect
Balancing use and over-use
What bad architecture is like
How to avoid problems
Bonus Link
10 Architecture Patterns X2
Poll of the Day
Where would you prefer to read my content? (The newsletter will still exist too.)
Polls are anonymous and just for fun. Voting will show you the results.
How Not to Architect
Introduction
“I’m going to architect the shit out of this project!” That might be what you’re thinking if you read my previous newsletter on moving up the food chain of software engineering and working on areas that AI can’t.
Like any new toy, the danger is to over-use it through sheer enthusiasm. But to be honest, I see engineers (and architects) over-engineering solutions all the time regardless, so this applies there too.
Focusing on, or being responsible for, architecture does not mean adding more architectural components. If you want to architect a project successfully, keep it simple.
Why it matters
The danger is that architecture often bites you when it’s too late to react. You’ll hear phrases like, “it worked fine during testing!” Of course, no plan survives contact with the enemy <cough> user.
Bad architecture is often complex to reason about, difficult to understand and deploy, and hard to debug. It’s typically over-engineered with too many components that are too loosely coupled.
When things go wrong with architecture, you’re left with the very uncomfortable situation of having to rip out major components (queues, databases, APIs), which often happens near the end of the project.
How to apply it
I used to work for a company that loved deploying large solutions in-house. I’d listen to an executive regularly berating teams with the phrase, ‘I can run that on my laptop!’
The point, which I think many overlooked, was that problems were being created by the desire for scaling that ultimately wasn’t required. The same could be said for the variety and number of components.
Simplicity is the ultimate sophistication
Don’t deploy architectural components that are not needed today just to add the ‘coolness’ factor. Do design with flexibility in mind and the ability to add components later IF scale is required.
And now you can go and architect the shit of your project!
Do you enjoy this newsletter? It would help me out if you could share it with a friend.
Poll of the Day
Where would you prefer to read my content? (The newsletter will still exist too.)
Polls are anonymous and just for fun. Voting will show you the results.
Ask Paul Anything
If you have a question, large or small, you can send it here..
Bonus Link
10 Common Software Architectural Patterns in a nutshell - Short and sweet if you have Medium access
10 Software Architecture Patterns You Must Know About - Long and detailed, if a bit unclear
Thank you for reading Paul Codes. If you know someone that would enjoy this newsletter feel free to forward it or refer them. Referrals earn rewards.
PS. If you’re a business and would like to sponsor this newsletter, please reach out!