Certain recipes have been around for centuries, passed down within a family or to a greater extent carried on by an entire nation. If you are Italian you will have a spaghetti recipe if you are from the south you probably have a bar-b-q recipe. I have little hope of anything happening like this in software engineering. What we have today is only a bunch of ingredients handed down in the form of the version of the language we use but the combination of these foundational apis to make a consistent morsel of logic for our applications to consume is constantly changing. For an industry that has a core focus on abstraction we seem to only abstract as much as will last 1 - 2 years, then a new api must be created and we must dub that old way useless. Your grandmas spaghetti recipe is garbage , this hipsters recipe made with JSON sauce is the new hotness. Beyond popularity and the cloning of tools that already work perfectly good there is a worse problem. Improper deprecation, bloated tool sets and confusing documentation plague framework. This can make picking up new tools feel more cumbersome than catalyzing. The creation of a framework should be at such a high level of abstraction that upgrading and learning it should be trivial, but it often isnt.
Recently I have adopted a number of Laravel framework projects. A 4.3 version which is one release old. I take a look at the docs seems like a standard php framework uses a bunch of symphony libraries. I try to set it up on a vagrant box and I am bombarded with a bunch of setup errors. In setting up the application I get my first laravel error about a folder not being present. For some reason a "views" folder is not generated in the template caching system and has to be manually created. Second I get a problem with an environment variable that is not in the config folder but is in a bootstrap.php file. The second problem would have been easy to find if I knew what I was looking for but google searches were showing me the Laravel 5.0 env setup. I finally see the version 4 way of setting up the environment and the question comes to mind why did this need to be changed? It didnt, but this change was made to make a better style but not create a better feature. These kind of changes should be should be at the top of documentation. For the most part they are useless and just make picking up a framework more difficult than need be.
Finally I get to building features and fixing bugs. I come upon a queue feature and start getting this strange bug where a queue job will drop off and stop sometimes and not other times. I use a command line script provided by Laravel to restart the queue and that seems to work but I cant find out why it stops. I eventually find out that its the length that the script runs with certain data and that this bypasses the error catching (I guess a timeout isnt an error in this case). I had to extend the timeout length for the SQS job in amazon. All these issues came up and I had a feeling that this system was too complex, it wants to make things easy but bites off more than it can chew and in the end becomes a burden to consume. I see why there is a website dedicated to "laracasts" (video documentation) but that shouldnt be necessary. If you need an entire domain dedicated to training thats a sign that your framework is not easy to use.
The difficulty to picking up a framework is one thing but bigger worry is to completely break implementations between versions. If a framework api has a feature then why is it necessary to not only change the implementation but also change the api? If the interface was bad before it should be changed in that version also. Its little things like that add difficulty to using a framework and add no useful functionality. At the very least a script or clear simple process should be made available to make upgrading easy. Isnt this something we as software engineers should be good at? Isnt this a problem we shouldnt have? The first thing a framework provides is an abstraction if that cant be done correctly how am I cant have faith in the underlying implementation.
Another task I needed to do was get php5.6 working. I had to add it to an install script on a fedora vm because thats what we use on our production server. This led to long set of steps because dnf (fedora's commandline update tool) did not allow me to download that specific version. I ended up having to research a specific provider (thanks remi) add this repo to my dnf instance and use it to download the correct version. This and my experience with frameworks (not just laravel, angular butchered it backwards compatibility so bad that it dropped the js from its name) that makes me uneasy about the future of our industry. When people order spaghetti they know what they are getting, we should be working for this with our software tools. I think this actually should be the most important part of open source software. Not providing new feature libraries, but creating abstractions that stand the test of time.
