Architecture - Keep it small and simple
Albert Einstein once said 'Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.'
During my consulting, I have seen many applications with very complex Architecture and wonder why it has to be so complex. What is the reason behind such an Architecture. Main reasons I always hear are, someone suggested that architecture, or some article talked about it, or it was implemented successfully in some other project earlier. Concepts like Two tier, Three tier, N tier, BAL, DAL, etc are good, tried and tested models that can fit almost any Architecture we can implement today. But does your application need it? But have you thought of implementing it from bare bones? We need to evaluate.
Today's application needs are different from a decade or 5 years back. Today customers demand mobile first approach, offline support, high availability, less infrastructure headaches. Is your architecture geared towards it?
A good Architect always keeps himself abreast with new and emerging architectures. Always asks himself, can I make it simple? can I easily replicate it for another project of similar nature? can I easily explain the architecture in 2 mins to anybody from developers to management without getting perplexed looks?
Always believe in KISS [Keep It Simple Stupid]
Written by Pooran Prasad Rajanna
Related protips
3 Responses
I fully agree. Although I'm not a mobile developer a lot of this carries over to what I do. The more moving parts you have the more potential places errors can occur. It's surprising how much you can get a accomplished with very little code. My thoughts are it should be clean, simple and it should just work.
I concur. And if it cannot be hold simple or is dependant on multiple sources throughout the developing-phase then a Bus Factor (http://en.wikipedia.org/wiki/Bus_factor) is a must. I've often seen architecture-models for eCommerce who weren't bad from a customer's view but so complicated structured that even the well-seasoned "maintainer's" had troubles to add additional code or edit it.
It's worth a lot more to invest time into planning your architecture to avoid headaches later on. If not for you, then for the person who has to maintain the code when you're gone.
@mike_horen yes, having multiple points of failure is a big pain to manage. That also adds lot of infrastructure to maintain. Its a nightmare. @rz47 talks about Bus Factor. Add that to the mix, and you have a deadly combination of unmanageable, cryptic code written by some guy who wanted to keep the secret sauce to himself.
@rz47 yes, by keeping the architecture simple, anybody can get on-boarded faster. I have seen a project where they had a custom framework which for a new guy took at least a week to learn and the people who mastered it do not want others to understand it well. That way they made sure they are always wanted.
