It is odd to start a post like this. Where the title can’t decide by itself what will be the topic of this piece of writing. Then again, seems that today’s developers nor architects can’t decide either in their projects.

Anyhow, the architecture of today looks a lot like design pattern discussions of old. Hammer it in, no matter if it makes sense. We can put it on the project description that we’re using <insert whatever here>. Sigh, here we go again. The discussion about patterns is something I addressed in another post, so it is not like it is out of the scope even in this. For now, let us focus on the architecture and how absolutes in it are making projects brittle and prone to full rewrites.

Just from the top of my mind, there were countless discussions what is the best way to start the new project. It is funny that it is asked as an answer usually is whatever is the latest hype in the software world. We were all there, we all share the same blame. Then again, months into the project, that small thing at the back of your brain starts nagging you. Starts slowly, but with every passing increment, it is getting louder. Is this the best way for going forward? Weren’t we better if we have chosen <insert whatever is alternative>? And slow descent into madness begins.

This is one of the things we often, in my opinion, get really, really, really wrong in the software world. We assume that the chosen architecture shouldn’t be questioned. Or the subject of a change. The architect must have picked this one for a particular reason. Yet we forget he is a person like us, not some ultimate being that can predict the future so many months/years/decades ahead. Remember Waterfall, we tried that. Fun times.

Starting with an assumption that we all make mistakes, where do we go forward? In my opinion, we need to be accepting that there is no way to know what the future will bring. Nor that despite whatever you heard at that conference by some “guru”, there is no silver bullet. Even when it comes to something as abstract as architecture. So check that ego at the door and accept that we have maybe chosen a direction that was not good. We learn, we adapt, and get out of it better than steering ourselves into that iceberg.

More often than not I hear: Monoliths are the way to start. And then there are terms there thrown around: majestic, modular, this or that kind of monolith. In my head, especially for greenfield projects, how do you even know what you’re going to end up at this stage is a monolith? You just started, building something new, with possibly more fog of war over it that you can’t even understand what is coming in the next sprint. Let where the entire project lands. Start by getting a sense of the project, by delivering something of value. To validate your assumptions and if this even has a future. Naturally, arm yourself with good practices about code design and stick with “monolith” for now. And I mean, for now, not allowing this to become a monstrosity with zero to no chances to be refactored when/if the time comes.

Learning about all the different architectural styles out there is something that comes as a given. They all have their tradeoffs. Cost, complexity, maintainability, et cetera. Getting sucked into the latest hype will, and this can’t be understated, land you in a heap of trouble. Been there, done that. And there are so many examples from big players shared, in many talks and blog posts. Yet the only thing we hear is that new shiny thing. And we forget all about the warning signs plastered on every meter of that road.

The architecture will evolve. And it needs to be natural, together with your project. Not because some architect said so. I was one at some projects and companies. Worked with a number of them. Not superhuman beings. Wrong more than not. The best ones will just know when it is not working, take the losses and move forward. For better of all.

The questions about chosen architecture will be sporadic at the beginning. As time passes, more and more of them will be coming. Till a point when it is a part of daily conversation. Dus, the sooner we start gathering that feedback and start evaluating the current state of things, the better. Define that new target architecture, and based on the feedback you gathered, should be easy. As said, should come naturally. So hence the term evolution mentioned a couple of times till now.

💡 Evolution: A gradual process in which something changes into a different and usually more complex or better form.

Isn’t this then work wasted? Sure, if you ask someone that is trained in the witchcraft of scrum. Or solely focused on features without thinking ahead. Then again, numbers can be crunched out. Sacrificing a bit of time to refactor and clean up the technical debt can be shown in a number of ways. Improved productivity, speed of delivery, etc. You’re doing it with a reason, as you have numbers already in front of you. And they’re not looking good. Just make them into a nice presentation with clear benefits to the business and start gradually. The Big Bang worked once. Don’t try repeating a process, go small and support your way with successes.

One of the triggers for this writing was just the latest warning from another team out there. And the reaction that it received. I am talking about Amazon Prime Team moving to the monolith. From serverless, and as many stressed out one of their major products is the cloud offering. Some of the reactions and comments, to be fully honest, baffled me. It reads like they said: You must use our lambdas for everythiiiiiing. Or anything else they have in their product base. No, that was probably your architect. Saw it at some conference, and thought he gonna be clever. And, maybe it works for your project. For the Prime team, it just didn’t. They were brave enough to come out and say it. So that others can learn. Like so many examples before this.

The baffling part for me is the polarity of these discussions. And reactions. It reads like Facebook posts. So glad I deleted that before it was cool to do so. Amazon is a business with many products, so don’t consider what they come up with as the way forward. They’re comprised of the same people as you and I. And we know how often we have no clue. You pick your poison. You live with it. And if that is serverless, it is your choice. Don’t base your architectural choices based on who has the best pitch sale on the hype of the day.

To close this up. Architecture, same as code, should evolve with the project and its needs. Otherwise, it becomes a bottleneck and the reason behind many frustrations. Keep that in mind for next time and plan accordingly. Invest in good code practices so that transition can be made as painlessly as possible. And don’t base your architectural choices based on the hype. Base it on project needs by understanding the tradeoffs of each of the styles out there. Pick one, that seems like a good choice. If it was even down the road, good for you. If it wasn’t, time to evolve.

Till next time, evolve your architecture like a Pokemon.