A few days ago, when analyzing the consumption of S3 from one of our header projects, we saw that the cost was skyrocketing. In...
It’s not the framework, it’s youmacklus
Reading this entry by Javi Santana about Frameworks of programming and the way in which they end up capturing the prominence of the project, I could not smile remembering my own experience.
The phases of every programmer
Every self-respecting programmer has gone through at least a couple of phases:
- I do not need any framework, I work better with my libraries.
- Oh! This framework is perfect! I’m going to redo all my projects with him.
Note: The second phase can be repeated with some assiduity, depending on how much we like to try new things :-). In addition, this can be changing between different frameworks of different languages, usually as we change work.
Programmers who are interested in their work try to be aware of what is emerging, and try new things if they have time. It is very easy to fall down before the simplicity that a new tool provides us, and want to apply it immediately to our daily work, thinking that it will simplify our life a lot (Hint: it goes wrong).
It is not until we get into a real problem that we do not discover the limitations that it has or can have, and when that happens, it is often too late to stop the process and we have to start over.
The best framework of all
I think it is not until several years have passed that you understand that which is the best framework (or the best tool) depends on the project and the specific circumstances within that project.
For example, I advise you to start any MVP with the language that controls the most, keeping in mind that if this project grows you will have to change the language almost certainly. If it is a mobile application, I advise you to use Framework as Ionic, which allow you to work for Android and IoS simultaneously.
But, above all, be very clear that the growth of a project can lead us to change the language or Framework as needed.
It’s business, stupid
As programmers we do not usually want to understand that the important thing is usually the business, and that the tool used does not usually matter to those who run the business, accustomed to thinking in a more abstract way.
This is how those horrible choices of languages and technologies are explained (like Java and Spring ) that are based on stability, extension and support, usually more rare in more modern languages. What need do I have to get involved with a modern language or Framework, when using Java or Spring I have fast and cheap access to programmers and support?
And no, those choices are not wrong, quite the opposite. A company is to make money, and using stable products instead of the latest language or fashion framework is a very smart choice.
Remember if someday you decide to take the step to have your own company.