Follow a Standard Architecture
Every single time I hear a team say “we follow MVC”, I know they are instantly lying. MVC is an architecture that translates to model-view-controller. There are clear distinctions between each layer. However, I know they are lying because if a team starts to analyze MVC, they realize there are much better alternatives. MVC is typically the default architecture taught through tutorials because it is one of the simplest. If a team adopts MVC, then they probably do not utilize an architecture at all, and the code they work in just organically creates a code base that is in MVC.
The development team must decide on an architecture, any architecture. Then, they must strictly enforce it on all modules. What this does is create a like-mindset and distributes domain knowledge. If every developer knows how a module should work, it greatly reduces development time. This means you end up spending more time fixing actual bugs than reverse engineering your own codebase.
- Onboarding a new developer is extremely fast and easy
- You won’t need to cut corners
- Development time is shortened; goodbye crunch times!
Adopting a standard architecture, and enforcing it, is something that will turn a project around overnight. At a company with an “MVC” architecture, I introduced a variant of the VIPER architecture. In the barest of terms, it is a 5 tier architecture with each tier having a single responsibility. In an incredible coincidence, while I was writing this, I received an email from a person who still works there:
“Hey man, it’s been awhile since we chatted and I have a ton going on right now but I just wanted to say.. I think you’d be surprised how much VIPER has made an impact here since you brought it. Even when higher ups of the company give presentations they are always talking about how much VIPER we have, etc. I see VIPER in many presentations, in addition to everyone basically knowing it as the go-to structure. Nice going!”
It was a huge battle getting VIPER to be adopted. Every step of the way I met resistance. I heard things like “it would be difficult for new people to pick it up” or “it would take too long to implement”. Eventually I broke everyone’s walls down and got people to start using it by explaining the benefits. Within days, they would change their mind and reluctantly admit they loved it. You will meet resistance with any change you are trying to implement, but as long as it is for the better, others will see the value and embrace it.
Originally published at Minerva IO.