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.
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.