I love it. This is a great process to determine which framework/library to choose from. I wonder, how would you modify the process and the questions, if you also wanted to evaluate the possibility of not using a framework at all?
For many of the questions, I would think that vanilla HTML/CSS/JS would be the clear winner, by a long shot, for instance:
does it have enough support from the community and/or the company behind it?
is it updated regularly and recently?
does it have a vision/roadmap that makes it future proof?
If we agree on this, the determination of when to use a framework then depends on the weight we give to the other questions and the way we answer them.
I'm curious, do you see situations where the quality / maintanability of a project would actually be increased by NOT using a framework? Or where the hidden costs / efforts of using a framework would be too great compared to using a vanilla solution.
What I'm especially interested in getting at is the sets of conditions / contexts, that make people decide to use a framework or not.
For example, if the project I'm working on has X views / pages, necessitates X functionality, has X requirements, is expected to last for X amount of time, will have X amount of people working on it, with X amount of experience etc... then I would consider using / not using a framework. You get the idea.
Well, most of the time I use 3-point-estimation to make visible the amount of work that's needed to implement a solution. And an estimation of how many hours it would take to maintain it (rough expert guess).
When looking at frameworks I need to be able to check off enough items of the requirements estimation to make it worthwhile for those hours. If there's more work into it than it saves and there aren't any other obvious benefits (it be on the short- or long term) I'm done with the framework.
Another criterium to bounce off frameworks is:
a bad reputation (ie: bad reviews from others who have used it)
bad security implemented or bad quality code
If I'm in a 5 person company and only 1 knows the language/architecture in which the framework takes a seat, it needs discussion if the team will invest into learning the framework. Often it isn't worth the deal.
But TBH: the critera are more experience based than actual hard figures. No excel sheet that I can sling up for you else I would.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love it. This is a great process to determine which framework/library to choose from. I wonder, how would you modify the process and the questions, if you also wanted to evaluate the possibility of not using a framework at all?
For many of the questions, I would think that vanilla HTML/CSS/JS would be the clear winner, by a long shot, for instance:
If we agree on this, the determination of when to use a framework then depends on the weight we give to the other questions and the way we answer them.
I'm curious, do you see situations where the quality / maintanability of a project would actually be increased by NOT using a framework? Or where the hidden costs / efforts of using a framework would be too great compared to using a vanilla solution.
What I'm especially interested in getting at is the sets of conditions / contexts, that make people decide to use a framework or not.
For example, if the project I'm working on has X views / pages, necessitates X functionality, has X requirements, is expected to last for X amount of time, will have X amount of people working on it, with X amount of experience etc... then I would consider using / not using a framework. You get the idea.
Well, most of the time I use 3-point-estimation to make visible the amount of work that's needed to implement a solution. And an estimation of how many hours it would take to maintain it (rough expert guess).
When looking at frameworks I need to be able to check off enough items of the requirements estimation to make it worthwhile for those hours. If there's more work into it than it saves and there aren't any other obvious benefits (it be on the short- or long term) I'm done with the framework.
Another criterium to bounce off frameworks is:
If I'm in a 5 person company and only 1 knows the language/architecture in which the framework takes a seat, it needs discussion if the team will invest into learning the framework. Often it isn't worth the deal.
But TBH: the critera are more experience based than actual hard figures. No excel sheet that I can sling up for you else I would.