When PHP Framework Sucks (5 Part Series)
Below is an image I used on my presentation named "When PHP Framework Sucks" when I tried to explain what is happening when you bind too much with the framework. The image is the footprint of an apartment, with no common angles in room corners. So as you might already imagine, when you move to such apartment, you have to build your furniture custom to the shape of the angles of the room. Otherwise, you won't be able to equip your new place with standard furniture you can find on the market.
Let's make this case even worse. Let's say you move to the new city, you don't have many options to choose, and you picked up this apartment. It is empty, and you start to equip it peace by peace. After a couple of years, you decide to move to another apartment. But what you do with your already existing furniture? You have to throw it away and get a new one once you moved to the next apartment because the new one has all new room properties, this time just standard one, so your "custom" furniture does not fit anymore.
Custom furniture is the perfect example of how developers shape their application around the framework and then they can't use it anymore in the other environment (other framework or libraries). Frameworks push you to structure your application in a specific folder structure, which is not bad by itself, but once you consider the framework change, it might be an obstacle. You might not change the whole framework as it is not what's happening very often, but sometimes just same framework, but different main versions completely make your app useless. I guess that everybody remembers migration from Zend 1 to Zend 2. I never heard of a success story, that one company accomplished that task.
That leaves us with the conclusion that every time a company or developer have to change a framework, she/he or company is pretty much forced to rewrite the whole application. Big refactoring or system rewriting is especially problematic with big systems which already earn a profit, and you can't just let it aside while you rewrite it in a new framework in peace. That's what I saw so many times in my career, that companies were unable to upgrade because of framework binding. They use to call that "Legacy problem" as that was something which "just happening over time" and you have zero control over it. Not many time I saw companies which enforce any DDD (Domain Driven Design) and forced the separation of their business from tools since frameworks are essentially just tools.
I personally believe, and I already proved it, that separation from framework brings long-term financial benefit to the company. No matter what new framework version brings, or do we want to integrate our component with other framework or library, we can do that without any pain, but only if we separated our business logic from the framework. I recently had a presentation of my project which potentially can live as long as PHP lives (and not drastically change). The project is fully equipped with 100% unit test coverage + behavior tests to ensure that the list of features always works. Also, the project is so independent and abstracted from the framework, that we can appy it into another framework in a matter of one week. My company believes that this project gonna live for longer than five years, which already brings us to the point that we won't have any 'major refactoring" or "big rewriting." So if this not prove financial benefits I can't find any more obvious example.