My point was solely that rewriting code--whether to a framework or for any other reason--is no reason to judge the original code as suspect.
Every team has their own reasons. You have yours, I have mine, but they’re the team’s reasons.
By the way...
> If I hand-roll my application with a cobbled-together framework
That is an interesting claim, but I do not find it to be a universal experience. Sometimes people--including myself!--do cobble together ad hoc frameworks, and in the long run a popular framework is almost always a better choice.
But sometimes, people just write a single app that does just what it needs to do without a lot of abstraction and indirection. They are ruthless about YAGNI. And the result is very easy to understand, because the cognitive load of reasoning about an app that is just an app is no greater than the cognitive load of reasoning about an app sitting on top of a framework you have internalized.
The problem is when people build their own framework and then build an app on top of their own framework. Sadly, this is usually the case, as they fall in love with building infrastructure in the hopes that future features can be added with just one line of code or dropping one file in one place.
That kind of thing is quite properly the domain of a framework, and very, very few teams should be writing frameworks.
tl;dr Let’s not set imply a false dichotomy between writing your own framework and using an off-the-shelf framework.
Every team has their own reasons. You have yours, I have mine, but they’re the team’s reasons.
By the way...
That is an interesting claim, but I do not find it to be a universal experience. Sometimes people--including myself!--do cobble together ad hoc frameworks, and in the long run a popular framework is almost always a better choice.But sometimes, people just write a single app that does just what it needs to do without a lot of abstraction and indirection. They are ruthless about YAGNI. And the result is very easy to understand, because the cognitive load of reasoning about an app that is just an app is no greater than the cognitive load of reasoning about an app sitting on top of a framework you have internalized.
The problem is when people build their own framework and then build an app on top of their own framework. Sadly, this is usually the case, as they fall in love with building infrastructure in the hopes that future features can be added with just one line of code or dropping one file in one place.
That kind of thing is quite properly the domain of a framework, and very, very few teams should be writing frameworks.
tl;dr Let’s not set imply a false dichotomy between writing your own framework and using an off-the-shelf framework.