“Reinventing the wheel is always a bad idea” – this is what we usually heard.
To reinvent the wheel is to duplicate a basic method that has already previously been created or optimized by others.
I don’t agree with. I love to reinvent the wheel and I think many devs in software development field are reinventing the wheel. If they are not, there would be only one framework and only one CMS in the world. Why Drupal, then WordPress, then Joomla? Why CakePHP, why Laravel, why Zend? If a framework or CMS has been developed and came out, why we need to reinvent another one of same purpose?
I always love to build an application with my own way without using any popular framework and their tools. It may take time longer than just plugging the wheel, but I feel it is faster for me. My expectation and requirements on third-party frameworks, libraries and modules are relatively high as I’m sometimes an over-thinking person. So none of them may likely satisfy me. If a framework or library or module is not smooth as I expected or has a bit deviation from my expectation, I will re-create it in my own if I can.
You might tell me “You can contribute them to improve or to fix bugs”. Yes, right, but there are a few things I always consider to contribute an open source project:
- Hacking own code is always faster than other’s code though some people like to hack other’s code.
- Some framework and library solutions are lacking in good documentation. Sometimes need to check and trace their source code. This is not productive.
- When I created an issue in an open source repo, it usually takes me time at least one day to wait for a reply from the original or core developers to confirm if it is a bug or it is a feature lack or I’m missing something of their usage because most solutions come from the other side of the world – the western countries.
- I may have to write test cases to reproduce to let the original or core developers know and understand the problem.
- I may have a long discussion about the issue with them. Even if a bug or a feature should be fixed or implemented, I may have to settle with them from their perspective to get approval. It could lead to take a few days to a few weeks or even several weeks.
- If I can even fix the issue, I will have to follow a formal procedure to contribute – fork and clone the repo, fix bug (or) add feature, write test cases, make a pull request, then wait for the pull request to be merged and wait for the new release. The time frame for this process can’t be imagined. It depends on the priority of the issue more or less. Hacking the core is always a bad idea and the formal contribution procedure should always be followed.
- Any suggestion of improvement to the repo may have to be rejected by the original or core developers as they’re likely trying to reduce the workload as less as possible if they have many issues in their queue. Even negative reply from them could be received.
All of these points are really unproductive for a serious critical application development with tight deadline. I often had to write workarounds in urgent, but that is not the way I love. Moreover, using any library solution necessarily pulls in extras and unused extraneous assets. It could lead to larger project file size unnecessarily and potential code bloat as well. This is another one I always consider in my project management.
The world is highly progressive with dependency management such as composer, npm, bower, etc. This is another headache for me and the developers from the slow-internet country. If we’re not lucky,
npm install or
bower install could break the modules because of several connection drops while running the command. Component and dependency inflation in the project could lead to the performance impact somehow.
So, working with offline resources as much as possible and as less dependencies as possible is always a good idea for me.
Writing slim and thin code with totally no or almost no dependency that producing compact solution is my passionate. That’s why I started PHPLucidFrame.