The PHP community is engaged in a discussion on whether or not developers should spend time writing new packages that solve existing problems with existing solutions. Ian Landsman uses Laravel as an example of a framework that wouldn’t have existed if nobody ever pushed the envelope of package development. While I agree that Laravel has been a huge leap forward for the PHP world, I happen to disagree with many of Ian’s points.
The fact that Laravel has been successful is not evidence in and of itself. There are hundreds if not thousands of small frameworks that have never taken off. Pointing to Laravel as an example of how developers can and should move forward is a logical fallacy known as post hoc ergo propter hoc, or “after, therefore because of.”
“Laravel reimplemented existing solutions, and so you should too” is the logical fallacy here. It assumes that Laravel succeeded because it reinvented the wheel, not in spite of it.
This is in no way meant as an attack on Laravel. Instead, I would argue that Laravel’s success happened as a result of the superb work done by Taylor. But the reason that Laravel has been successful is because Taylor innovated. In fact, Taylor’s framework makes heavy use of existing packages that are part of other frameworks (Symfony in particular). Taylor took packages he liked, and wrote packages to fill in the gaps.
And this is where the balance lies. Taylor didn’t have to completely reinvent the wheel. Instead, he could stand on the shoulders of others who had come before and use their work. That let him focus on doing what needed doing: innovating the way PHP developers actually write applications.
There are certainly great learning opportunities in writing a framework, reimplementing a package, or discovering how and why certain things are done in certain ways. And for developers who believe there’s innovation to be had, they should by all means develop a new package or framework. The problem comes when somebody just decides to “make another X”. Creating a new cache library, database object or API wrapper without innovating or considering what’s already out there is a pointless waste of time.
Worse, when we needlessly reinvent the wheel without innovating, we’re taking crucial time away from what we should be doing: solving the business problems we actually have. I’ve heard it described that refusing to use existing and adequate packages in favor of your own approach is equivalent to stealing from your employer. This makes sense, because unless you’re adding something new, the work you’re doing brings zero value to the conversation.
When innovation and invention is necessary, every developer should take advantage and do both. But when existing solutions are adequate to the problem at hand, we should use them.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."