2 ms·

You might be thinking of this excellent article by Joel Spolsky: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelon

You might be thinking of this excellent article by Joel Spolsky: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... (Ironically, that post is about Netscape and the rewrite, Mozilla, ended up growing as a nonprofit far beyond Netscape's original scale.) The so-risky-it's-almost-certain-to-fail approach is a big bang rewrite. Stop the world until the rewrite is done. That's not what we're doing. A tiny bit of our GraphQL schema is _already_ running in production atop new services written in Go. We're going to do this step-by-step, while keeping the site running, _and_ adding committed features next year. It's still a huge investment and comes with risks, but it's an incremental process and we'll be able to track the progress at every step.

mntmoss 7y ago
So long as your data has well-defined interface boundaries on it, this is a good way to de-risk rewrites. It really depends on the current state of the codebase. If there's a tangle of dependencies, then they have to be cleared out or facaded away to a testable interface, or else that part of the port will be a shot in the dark. And if you have the interfaces in hand, the language itself becomes considerably less important, since more of the code is subsequently dependent on your own system and not really the outer ecosystem. It's the projects that have coded "to the metal" on their existing platform that have the biggest issues with keeping up their flexibility.
- dangoor 7y ago
  Given that this is mostly about our backend systems, we've got one big interface in front: our GraphQL schema. Our system isn't perfect, but a couple of years ago we spent a good deal of effort detangling our monolith. This plan wouldn't have been an option had we not done that.

mntmoss 7y ago

So long as your data has well-defined interface boundaries on it, this is a good way to de-risk rewrites. It really depends on the current state of the codebase. If there's a tangle of dependencies, then they have to be cleared out or facaded away to a testable interface, or else that part of the port will be a shot in the dark. And if you have the interfaces in hand, the language itself becomes considerably less important, since more of the code is subsequently dependent on your own system and not really the outer ecosystem. It's the projects that have coded "to the metal" on their existing platform that have the biggest issues with keeping up their flexibility.

dangoor 7y ago
Given that this is mostly about our backend systems, we've got one big interface in front: our GraphQL schema. Our system isn't perfect, but a couple of years ago we spent a good deal of effort detangling our monolith. This plan wouldn't have been an option had we not done that.