It is not as simple as this because of the time component of software engineering. It is necessary to both use what's right for the project in the moment and to

It is not as simple as this because of the time component of software engineering. It is necessary to both use what's right for the project in the moment and to use what's right for the project's future evolution. Of course you rarely know for sure what that evolution will look like, but if a group of people think a project is worth working on, they probably think it will live and continue evolving for awhile, in which case it is necessary to make choices aimed at supporting that evolution. It is very often the case that a framework is not "what's right for the project" in the moment early on, but it is usually the case that it is what's right for the project to evolve. The alternative is for a newly invented framework to be built up over time, and this is not a good use of time and often results in a mess. A framework always feels silly when you're just doing some fairly simple thing once. But if you anticipate doing similar things tens or hundreds of times, it is usually worth the cost up front to avoid reinventing wheels later.