3 ms·

I am not expert, but I have listened to a course where the teacher said that we should use many frameworks. When you develop a project for a client, you select

I am not expert, but I have listened to a course where the teacher said that we should use many frameworks. When you develop a project for a client, you select the current best framework and you do not change until you really need to change. Then when you have a new project for a new client, you use the new best framework. I do not know if it is feasible in all cases. Having many frameworks allows to anticipate the problems, cost and benefits of a migration. I think it is interesting for developers who will have more interesting work. The cost of many framework may be compensate by the fact that it is easier to associate a migration cost to a client.

rypskar 13y ago
As I see it if you are developing something small for a client, you want to get something created ASAP get it out and forget about it. So yes, then it makes sense to use the current best framework and write code that is tightly coupled with it. But when you start to create larger systems, you will have to think about maintaining the code, adding new features and fixing bugs. Then it is not so fun if your code depends too much on a framework and you don’t update it when new versions are released. It is not fun googling for something and in the one result you get someone is pointing out that you are using an obsolete framework, and noticing that the post is 10 years old. (Did happen with some software I used to be developer on)
- webreac 13y ago
  There is also an answer for that: do not build large system. Split them into largely independant parts (I think this is called silo architecture). When one of your silos get outdated, you replace it.
  - csixty4 13y ago
    > (I think this is called silo architecture) Might be called that now. When I was working on big systems it was called Service Oriented Architecture.

3 ms·

I am not expert, but I have listened to a course where the teacher said that we should use many frameworks. When you develop a project for a client, you select

by username42 13y ago

rypskar 13y ago
As I see it if you are developing something small for a client, you want to get something created ASAP get it out and forget about it. So yes, then it makes sense to use the current best framework and write code that is tightly coupled with it. But when you start to create larger systems, you will have to think about maintaining the code, adding new features and fixing bugs. Then it is not so fun if your code depends too much on a framework and you don’t update it when new versions are released. It is not fun googling for something and in the one result you get someone is pointing out that you are using an obsolete framework, and noticing that the post is 10 years old. (Did happen with some software I used to be developer on)
- webreac 13y ago
  There is also an answer for that: do not build large system. Split them into largely independant parts (I think this is called silo architecture). When one of your silos get outdated, you replace it.
  - csixty4 13y ago
    > (I think this is called silo architecture) Might be called that now. When I was working on big systems it was called Service Oriented Architecture.