The problem arises when people use something just because they think it's cool and someone wrote about it on Twitter and not because it has clear advantages com

The problem arises when people use something just because they think it's cool and someone wrote about it on Twitter and not because it has clear advantages compared to other solutions. Do not blame design patterns if you don't understand them. But you can blame book authors for not explaining it to you properly; maybe they don't understand the patterns too. Also I disagree about DB and normalization: in most cases the best choice will be SQL DBMS and normalized data. Please let me explain why: - normalization saves you from duplicating data; MongoDB will make you do the opposite. Updating the data will be more difficult and you will spend more time writing the code. - fixed schema will make it easier to understand DB structure for new developers and helps you to detect errors; with MongoDB all invalid data will go straight into the storage and you will spend additional time fixing them later. - foreign keys and transactions save you from saving inconsistent data into the database; MongoDB won't help you with this. Designing a database properly doesn't require much thinking, it is a natural thing and you are not losing time. But I understand what the author is talking about. Recently I was using two of Google's products, Doubleclick for Publishers and Google Analitics. Their UI is super slow, at least on my hardware. One Chromium tab with DFP page consumes over 700 Mb of memory. When I decided to inspect it, I found that on DFP page they used Dart "apps" compiled to JS; each of them was not less than 2.4 Mb. Even the "changelog" app which was just displaying information about recent changes (yes, they did it as a separate app). In Analytics UI, they decided to use Material Design with large number of animations, it is very slow and UI elements are too big for 1280px wide display. It looks more like your legacy enterprise app written 10 years ago in Java and IIS, rather than a Google product. They could just use something simple, like Symfony Framework and jQuery and avoid most of those problems. I think the reason why they didn't is because Google employs smart people and gives them a boring job; to entertain themselves they tried to play with something new, like Dart or make Android-like UI but didn't have enough time to do it properly.