I find it pretty interesting that the only real concern was "can this team solve my technical problem using the best tools in the shortest amount of time" but did not seem to consider things like, "What happens when this team moves on". One of the biggest assumptions that I've made is that when choosing tools, choosing the most popular ones gives you the highest chance of bringing someone on board who already groks them, finding learning material, etc.
I seem to be noticing more often now that "the best tool for the job, for the person, at the time" is completely acceptable. I feel as though this didn't used to be the case, and I know a lot of more "established" engineers who believe it's naive to choose tools based on an inclination or personal/team preference. While in this case, we're getting less code in the dependency, I'm highly suspicious of how their working knowledge, method of code organization, etc... can be transferred over time.
Ultimately though, knowing what actually happened over time with this project would be the most interesting. Does he eventually find new team members who convince him to switch back to a framework that is more widely understood and practiced?
> but did not seem to consider things like, "What happens when this team moves on".
FTA:
> 3. Cuba itself is extremely easy to work with because it barely does anything. You can read the entire source in 5 minutes and understand it completely. I'm confident future teams could pick it up.
I guess the main concern here wouldn't be Cuba, but the "handpicked solutions for common problems that a web app would face" added by the development team.
> While in this case, we're getting less code in the dependency, I'm highly suspicious of how their working knowledge, method of code organization, etc... can be transferred over time.
I seem to be noticing more often now that "the best tool for the job, for the person, at the time" is completely acceptable. I feel as though this didn't used to be the case, and I know a lot of more "established" engineers who believe it's naive to choose tools based on an inclination or personal/team preference. While in this case, we're getting less code in the dependency, I'm highly suspicious of how their working knowledge, method of code organization, etc... can be transferred over time.
Ultimately though, knowing what actually happened over time with this project would be the most interesting. Does he eventually find new team members who convince him to switch back to a framework that is more widely understood and practiced?