I had the pleasure of hearing Larry Garfield (@crell) give a keynote at Sunshine PHP 2014 (@SunshinePHP). He started out with a history of how difficult it had been to share code – no standards, no easy way (other than cutting and pasting), no easy way to maintain that shared code, etc., and we were fighting against years of “sharing” being “bad for business”.
Given 2 ways to solve a problem, choose the approach that results in less code in the world.
–Larry Garfield (@crell)
Zoom ahead several years. PHP 5 is stable and expanding, but adoption was low. We had finally found a compelling reason to band together. Major PHP projects worked together to help push the adoption of PHP 5. Standards discussions weren’t far behind. With the advent of Github, we now had an easy way to share code and maintain shared projects. Composer popped up, breaking down the barriers to including shared code in projects.
Where does this leave us? We have eliminated the technical barriers of sharing code. We have even begun to break down the perception that sharing code will hurt business. So what’s next?
What if we all stopped writing code and started sharing code? No really. What would happen if we stopped using our brain power to write code that’s already been written? How many problems could we solve if we put that brain power to use solving new problems? What about old problems that we have worked around for generations because we could not find a way through? We have an incredible amount of brain power available, but we are spending it _typing_ code. How much time are we wasting maintaining multiple copies of basically the same code?
I’m not saying that existing code should not be improved upon, and I’m not saying that different people can’t approach the same code slightly differently and both of those approaches will result in a useful output. I’m saying, the goal of our work should be to reuse existing solutions, and then to create code when we have a new problem to solve.
This is a grand pie-in-the-sky statement, of course. We all need to make a living, and we often need to do what the system demands of us in order to make that happen. But…if we all shift our thinking a little – not even a lot, just a little. If we all take a second look at the code we are about to write; the project we are about to build. Then, maybe, we can regain a little bit of effort that we can redirect somewhere else, and when we do, I can’t wait to see what we will build.
Update: April 19, 2014
I had a Twitter conversation with Phil Sturgeon after publishing this post. The conversation boiled down to Phil pointing out that this post may not be clear enough as to what my viewpoint is. Here is the Twitter-length summary of what I meant with this post:
My point is that writing code should not be the 1st response. Finding if shared code exists should be the 1st response.
https://twitter.com/e3BethT/status/457207489851686913
I wanted to add this to make sure there’s no confusion. I’m not saying that you should blindly use all shared code. However, when presented with a situation in which you need some code, I hope that your first action will be to check if there is a shared code solution available. If there is one, but it’s not quite what you need or is not secure/well-formed, consider contributing improvements to the shared code to make it a useful piece of code. If there is not a shared solution available, consider creating a solution in a sharing-friendly way (meaning, please share your solution once you’ve built it so the next person in this situation will be able to find a shared code solution).
Hopefully, this helps make my thoughts more clear. I’d love to discuss this more in the comments or on Twitter (@e3betht).
Hi Beth, Interesting view. I believe with Composer we are starting to do it.
It’s also interesting to note that this should be applied to a lot of things in life. Too many companies trying to “solve” the same issues.