4 ms·

> If your code had been as easy to understand as you say it > is there would have been no need to re-write it. In theory, only difficult-to-understand and/or

> If your code had been as easy to understand as you say it > is there would have been no need to re-write it. In theory, only difficult-to-understand and/or difficult-to-maintain code is rewritten. In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. I wouldn’t assume there’s any correlation whatsoever between the quality, readability, or maintainability of code and whether it gets rewritten when a new team arrives. Sometimes, that’s just what happens, whether we think it’s justified or not.

deleted 11y ago
[deleted]
jonathankoren 11y ago
This. I've seen thing rewritten for purely political purposes more often than technical reasons.
- exodust 11y ago
  Same here. I've also seen the re-written code perform no better than the original but nevertheless celebrated as improved. I guess when billable hours are at the heart, nobody wants to say "and we rebuilt the homepage for what turned out to be no reason at all, but kept us busy for a few weeks".
morgante 11y ago
> In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. And that's perfectly valid. In fact, it's one of the best reasons to use a framework. If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc. On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React. That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.
- braythwayt 11y ago
  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.

deleted 11y ago

[deleted]

jonathankoren 11y ago

This. I've seen thing rewritten for purely political purposes more often than technical reasons.

exodust 11y ago
Same here. I've also seen the re-written code perform no better than the original but nevertheless celebrated as improved. I guess when billable hours are at the heart, nobody wants to say "and we rebuilt the homepage for what turned out to be no reason at all, but kept us busy for a few weeks".

morgante 11y ago

> In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. And that's perfectly valid. In fact, it's one of the best reasons to use a framework. If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc. On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React. That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.

braythwayt 11y ago
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.