Pick your Poison

As we grow older and hear about silver bullets, we know that someone is trying to sell us snake oil. Developing software is not much more than a series of compromises.

When I read comparisons between architectures and technologies, I look at the arguments being presented and the context. Often posts and “hot takes” have arguments, but most lack context. As a junior engineer reads that MVVM is the way to go, their belief in such a statement is proportional to the author’s number of followers. The more street credit you have, the less scrutiny you get. As a reader, you might be charmed into thinking that because MVVM worked for a random stranger, it will work for you as well.

Personal experiences shape the way we think and behave. If we had a bad experience with MVC, we assume that MVC is terrible. If we see an engineer encouraging others using MVC, we think that the person is stupid. We evolve and hopefully become better by going through life’s hardships.

Being mentored by someone that didn’t know how to use MVC might make us think that the fault was with the architecture and not with Chad. He was a pretty cool guy; and the codebase was already a mess when he joined, anyway.

When we evaluate a tool ask the following: is this the best option for my team? Technology is a significant factor. For instance, we wouldn’t use a dependency that is poorly maintained. Likewise, we might avoid an architecture that is not well known in the community. Technology is not the whole picture, although less experienced engineers will think so. The human factor is more substantial. Does the team know how to use the technology? ReactiveSwift, and other FRP* libraries are often canned because of this question. How long would it take us to onboard a junior engineer? How difficult is it to hire people with know-how in the approach? Questions like these guide us to a final decision.

At an extreme, even with the amount of flak that Viper gets, it can be the right solution if the team is delivering quality software on time.

Twitter, and more serious places are usually riddled with “use X because Y”, or “Z is shit because I had a bad experience”. Pruning subjective experiences is important, when making an objective decision about how you are going to architect your next app, or introduce a new tool.