3 ms·

As long as it works there's no point modernizing it. At some point when you won't be able to update it anymore you'll pay someone to build you a new one with al

As long as it works there's no point modernizing it. At some point when you won't be able to update it anymore you'll pay someone to build you a new one with all the bells and whistles of contemporary frameworks-which in most cases are overhyped piece of junks.

nindalf 6y ago
Never rewriting is a great way to save costs in the short term and also shoot yourself in the foot long term. Unemployment systems written in COBOL were perfectly fine until we found they weren’t in March 2020. Maybe we should have rewritten those 20 years ago? That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. Let’s say GP and his coworker switch jobs in the next couple of months. Who is going to maintain an application built on a framework no one understands? At that point you’d have no choice but to rewrite it except now you don’t have the knowledge of how the existing system works. All of this without even getting into the security implications of using a framework that no one else is.
- irrational 6y ago
  The security thing doesn't concern me too much. In 20 years we haven't been hacked. Plus my company (Fortune 100) has literally hundreds of people that work in the website security department. They have gone over our code with a fine tooth comb and are constantly monitoring and trying to hack our site before someone else does. So far they haven't found anything in many years.
- unclebucknasty 6y ago
  >That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. The difference is this framework still runs on a modern platform (assuming it uses JS and other Web standards). So, it's dated only WRT other frameworks, which come and go anyway. So, unlike with COBOL (and "Cobalt"), it's supported by the platform of the day with standards many current devs know.
slifin 6y ago
Frameworks give a good knee up but not enough to make programmers interchangeable with no investment in learning A 2-decade old project probably would take such a long time to re-write into a modern framework that the time would be better spent investing in devs willing to work with your system Particularly in JS, you may find after the re-write your framework of choice moves on without you and you're back to square one (though this is slowly stabilizing) Obviously, there are exceptions, maybe the new language has persistent data structures or strong concurrency primitives that would be difficult to home grow that should move the needle of your decision making, in which case you may want to use new tech at the edges of your system, but you'll need to make peace with the fact you'll likely never finish the full migration and it will complicate onboarding, ultimately this should align with the personality of your team I think
- unclebucknasty 6y ago
  >you may find after the re-write your framework of choice moves on without you and you're back to square one A simple guideline might be to only roll a new framework if it's significantly advancing the state of the art WRT modern frameworks. That is, addressing conceptual weaknesses or the like. OTOH, if it only offers incremental improvement and/or could easily be adapted by a current framework, then probably not worth the effort. So, we're talking paradigm shifts here. For instance, we probably don't need any more HTML template-driven, reactive frameworks.

nindalf 6y ago

Never rewriting is a great way to save costs in the short term and also shoot yourself in the foot long term. Unemployment systems written in COBOL were perfectly fine until we found they weren’t in March 2020. Maybe we should have rewritten those 20 years ago? That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. Let’s say GP and his coworker switch jobs in the next couple of months. Who is going to maintain an application built on a framework no one understands? At that point you’d have no choice but to rewrite it except now you don’t have the knowledge of how the existing system works. All of this without even getting into the security implications of using a framework that no one else is.

irrational 6y ago
The security thing doesn't concern me too much. In 20 years we haven't been hacked. Plus my company (Fortune 100) has literally hundreds of people that work in the website security department. They have gone over our code with a fine tooth comb and are constantly monitoring and trying to hack our site before someone else does. So far they haven't found anything in many years.
unclebucknasty 6y ago
>That would have saved the NJ Governor from putting out a request for “Cobalt“ programmers in the middle of a pandemic. The difference is this framework still runs on a modern platform (assuming it uses JS and other Web standards). So, it's dated only WRT other frameworks, which come and go anyway. So, unlike with COBOL (and "Cobalt"), it's supported by the platform of the day with standards many current devs know.

slifin 6y ago

Frameworks give a good knee up but not enough to make programmers interchangeable with no investment in learning A 2-decade old project probably would take such a long time to re-write into a modern framework that the time would be better spent investing in devs willing to work with your system Particularly in JS, you may find after the re-write your framework of choice moves on without you and you're back to square one (though this is slowly stabilizing) Obviously, there are exceptions, maybe the new language has persistent data structures or strong concurrency primitives that would be difficult to home grow that should move the needle of your decision making, in which case you may want to use new tech at the edges of your system, but you'll need to make peace with the fact you'll likely never finish the full migration and it will complicate onboarding, ultimately this should align with the personality of your team I think

unclebucknasty 6y ago
>you may find after the re-write your framework of choice moves on without you and you're back to square one A simple guideline might be to only roll a new framework if it's significantly advancing the state of the art WRT modern frameworks. That is, addressing conceptual weaknesses or the like. OTOH, if it only offers incremental improvement and/or could easily be adapted by a current framework, then probably not worth the effort. So, we're talking paradigm shifts here. For instance, we probably don't need any more HTML template-driven, reactive frameworks.