As my company has undertaken the journey that is Magento 2 we find ourselves constantly researching how others in the Magento community have solved similar problems. We are grateful for so many contributors willing to spend the time and effort to write up explanations of how they chose to solve problems and share with the rest us.
We are constantly searching for the proper balance between the quick solution that meets the customer's exact request (and current budget) and the fundamentally sound solution that takes longer and maybe is more than the customer really wanted to tackle and way more then they wanted to spend. Much like in Magento 1 there are often lots of ways to accomplish a single task in Magento 2. Unlike Magento 1, a developer can carefully craft a change that is injected at just the right time in the request life cycle with limited impact to the rest of the system. Unfortunately, it is still too easy for a developer to make changes that have terrible side effects as what they believed was a small change for some specific scenario actually was a generic function that is called by lots of different processes with data in all sorts of different states.
So how do we collectively learn? .. how do we learn to customize Magento better? ... how do we impart the wisdom we learn to others? ... It is my hope that this blog can play a part in this process. So much of the intellectual property on Magento is recanting a rote implementation for a specific problem. This sort of help can be exactly what you need ... or not. What if what you need is sorta like this other developers problem but not quite ... Did the other developer approach the problem correctly? Does the solution align well with the core Magento architecture? Is the solution one that is made to last? These are harder questions ... but just as important as solving the problem at hand.
As many other Magento developers can attest to when they take over projects build by other teams, there are a LOT of bad implementations. It is difficult to tell a customer that while their system "looks" right from the front-end perspective, the underlying implementation is a disaster ... that there is significant work to be able to upgrade their Magento version due to the customizations put in place ... that core Magento features don't work because the previous team violated the core Magento framework assumptions ... that the previous team gave them a solution that was not maintainable.
We are not perfect, we make mistakes, we make bad design decisions, but we don't want to. We want every customer to have a system that is built to last with thoughtful design and core Magento architecture principles maintained. This blog is part of our effort to explain more than just the how ... but the why when executing custom Magento development.
We don't want to just give fish to eat, we want to teach people how to fish ...