4 ms·

Isn't there a quote somewhere along the lines of "full rewrites are suicidal?" Seems pretty risky to me.

stoicShell 7y ago
The saying only applies when your product is software itself, not in most cases where software is just the means to deliver your product — here a website providing education in video form etc. Besides, the reality is that most business software out there gets rewritten every 3-15 years (really depends on use-case and conditions, but on average 4-5-6 years is a good bet). After some time it's just not worth it to keep refactoring, you'd rather start anew with hopefully better tech and certainly with better knowledge of your problem — they say you should write everything 3 times to make sure you really nailed it. In many businesses, these rewrites would constitute a new major version, more comparable to the feeling we always got in the waterfall era — new version = big changes, new UI, new stuff. That's when it's possibly lethal, if you really break the thing, and that thing is your product, not a means to it.
- guitarbill 7y ago
  the number of failed migrations, modernizations, and "tech transformations" in non-software industries, as well as the number of consulting outfits and their profits doesn't seem to back this up. [0] IT disasters now part of modern life - https://www.afr.com/technology/it-disasters-now-part-of-modern-life-20160628-gptyw6 https://www.afr.com/technology/it-disasters-now-part-of-mode... [1] Number of IT failures at banks and other firms is unacceptable, say MPs - https://www.theguardian.com/business/2019/oct/28/number-of-it-failures-at-banks-and-other-firms-is-unacceptable-say-mps https://www.theguardian.com/business/2019/oct/28/number-of-i... [2] The Biggest IT Failures of 2018 - https://spectrum.ieee.org/riskfactor/computing/it/it-failures-2018-all-the-old-familiar-faces https://spectrum.ieee.org/riskfactor/computing/it/it-failure... we can argue whether these are "rewrites", but big changes can be rewarding but are inherently risky. balancing this is hard, and rewrites uncover and introduce the unknown unknowns.
  - stoicShell 7y ago
    That will make for some pretty salient readings, thanks for the links. There are obviously cases of failure. I don't know the stats. I'm speaking mostly of small/medium businesses, where size and complexity are different.
    - guitarbill 7y ago
      that's fair, most of those are "you get what you pay for" and hardly the fault of a competent, well-meaning, but naive dev team. problem is it's much harder to get data on small businesses. i think one thing we can agree on is that the only thing users hate more than change is breakage. rewrites are a valid tool in a long-term strategy, just as debt is for finance. but for most people, incremental change has a bigger, smoother RoI. it sounds like this is kind of what KA is doing. although the timeline seems aggressive and the whole thing absolutist, being stuck on Python 2 is a risk now, too.
      - stoicShell 7y ago
        I think we agree on the general perspective, yes — we'd probably agree as a team with known (ad hoc) conditions and goals. Data on small businesses is hard indeed. I'm only speaking anecdotally from the MSP / software shops perspective, the "tech guys" of most businesses who don't in-house IT. Also from a European perspective, so that might make a big difference — we're, ahem, let's say not as involved, interested, or capable in all things "technology" as a general population (I didn't say luddites but that's how it feels sometimes, compared to the vibe I get in NYC or rich Asian cities).
dangoor 7y ago
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.
ElonMuskrat 7y ago
> Isn't there a quote somewhere along the lines of "full rewrites are suicidal?" This is just dogma. Often it's the wrong choice, but sometimes engineers have very good reasons to re-write a system. As with all decisions, tailor the solution to the situation - not the other way around.

The saying only applies when your product is software itself, not in most cases where software is just the means to deliver your product — here a website providing education in video form etc. Besides, the reality is that most business software out there gets rewritten every 3-15 years (really depends on use-case and conditions, but on average 4-5-6 years is a good bet). After some time it's just not worth it to keep refactoring, you'd rather start anew with hopefully better tech and certainly with better knowledge of your problem — they say you should write everything 3 times to make sure you really nailed it. In many businesses, these rewrites would constitute a new major version, more comparable to the feeling we always got in the waterfall era — new version = big changes, new UI, new stuff. That's when it's possibly lethal, if you really break the thing, and that thing is your product, not a means to it.

guitarbill 7y ago
the number of failed migrations, modernizations, and "tech transformations" in non-software industries, as well as the number of consulting outfits and their profits doesn't seem to back this up. [0] IT disasters now part of modern life - https://www.afr.com/technology/it-disasters-now-part-of-modern-life-20160628-gptyw6 https://www.afr.com/technology/it-disasters-now-part-of-mode... [1] Number of IT failures at banks and other firms is unacceptable, say MPs - https://www.theguardian.com/business/2019/oct/28/number-of-it-failures-at-banks-and-other-firms-is-unacceptable-say-mps https://www.theguardian.com/business/2019/oct/28/number-of-i... [2] The Biggest IT Failures of 2018 - https://spectrum.ieee.org/riskfactor/computing/it/it-failures-2018-all-the-old-familiar-faces https://spectrum.ieee.org/riskfactor/computing/it/it-failure... we can argue whether these are "rewrites", but big changes can be rewarding but are inherently risky. balancing this is hard, and rewrites uncover and introduce the unknown unknowns.
- stoicShell 7y ago
  That will make for some pretty salient readings, thanks for the links. There are obviously cases of failure. I don't know the stats. I'm speaking mostly of small/medium businesses, where size and complexity are different.
  - guitarbill 7y ago
    that's fair, most of those are "you get what you pay for" and hardly the fault of a competent, well-meaning, but naive dev team. problem is it's much harder to get data on small businesses. i think one thing we can agree on is that the only thing users hate more than change is breakage. rewrites are a valid tool in a long-term strategy, just as debt is for finance. but for most people, incremental change has a bigger, smoother RoI. it sounds like this is kind of what KA is doing. although the timeline seems aggressive and the whole thing absolutist, being stuck on Python 2 is a risk now, too.
    - stoicShell 7y ago
      I think we agree on the general perspective, yes — we'd probably agree as a team with known (ad hoc) conditions and goals. Data on small businesses is hard indeed. I'm only speaking anecdotally from the MSP / software shops perspective, the "tech guys" of most businesses who don't in-house IT. Also from a European perspective, so that might make a big difference — we're, ahem, let's say not as involved, interested, or capable in all things "technology" as a general population (I didn't say luddites but that's how it feels sometimes, compared to the vibe I get in NYC or rich Asian cities).

dangoor 7y ago

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.

ElonMuskrat 7y ago

> Isn't there a quote somewhere along the lines of "full rewrites are suicidal?" This is just dogma. Often it's the wrong choice, but sometimes engineers have very good reasons to re-write a system. As with all decisions, tailor the solution to the situation - not the other way around.