4 ms·

My biggest suggestion is to look into ways that the transition can be done in stages, rather than trying to replace everything in one big swoop. This is likely

by rurp 2y ago

My biggest suggestion is to look into ways that the transition can be done in stages, rather than trying to replace everything in one big swoop. This is likely doable, especially since you are already having to rely on outside tools. Then to start building, hire a small team (employees or freelancers) and have them create a single piece of functionality that can be swapped out from the current workflow. This type of approach will limit the upfront costs and give you a much better idea of how feasible the replacement will be as a whole. It will almost certainly go smoother as well. Every rewrite/replacement of a large software project runs into a lot of unexpected challenges and complexity that will have to be ironed out, and this limits the disruption at any one time. There are a lot of factors in whether or not to go this route, but it's certainly plausible that it's a good decision. I worked for a smaller company that did something similar and gradually built out their own internal workflow software tailored to the business. Overall it worked out quite well and they ended up with much better software at a lower price than they would have paid for outside tools. I'm sure there are plenty of examples of the opposite result as well. You're right to be cautious but I think it's an idea worth exploring further.

L-four 2y ago
This is my experience it's almost always better to continue working with the existing solution as you slowly replace it's features with your own until you no longer need it. The replace everything at once approached is fraught with risk.
theshrike79 2y ago
Strangler Fig pattern works really well: https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html You split out segments of the old application and rewrite it, slowly moving traffic over - eventually slowly strangling the old application and replacing it with new parts.
- hobofan 2y ago
  It's a good pattern in theory, and the main route I'd personally choose most of the time. However in practice, depending on the kind of application, it can be really hard to do those gradual rewrites in practice, especially if you want to modernize by introducing new programming languages. E.g. for a legacy project on the JVM, how do you gradually shift things over to Kotlin? Or for the same project how do you go from Java to Rust? Of course you can also do that by splitting things out into REST services, but now you have to handle reliability issues of your transport layer and have to figure out how to pass large data through it and/or how to handle a barage of calls that were previously swift in-memory function calls. So in practice there are a boatload of potential challenges when doing gradual rewrites, and in my experience very few people have the expertise to pull them off in practice.
  - marcosdumay 2y ago
    On the case of the OP, with a database, different pieces of software interact over the database. It's the simplest case.
- JamesSwift 2y ago
  Ive never seen it work in practice. Every time I see it end up with Appv1, Appv2, Appv3 all running at the same time because the new systems cant move quick enough to add new features so they get added to the older versions. But the newer systems offer unique things the older didnt. So they all coexist and never die.
  - marcosdumay 2y ago
    There's something wrong with your experience, because the entire point of making a new system is that it will eventually move faster than the old one. Maybe your strangling software is still too ambitious.
  - theshrike79 2y ago
    That sounds like you're trying to rewrite the whole app, NEVER do that[0]. You shouldn't end up with appv1, v2, v3. You should have appv1 along with appv1-foobarmeasurement-v2 running. Then you slowly move traffic to v2 of foobarmeasurement until it can handle 100% of the load and has all the features - then you remove that feature from appv1 completely. Then you GOTO 10 and pick a new feature to slowly strangle. [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
    - JamesSwift 2y ago
      My point is that if the rewrite is not able to be classified as a refactor, it wont work. It has to be entirely invisible to the user (and product side of the org). Otherwise, it is never going to be completed.
      - theshrike79 2y ago
        That's literally the point of the strangler fig pattern :) The difference between a rewrite and refactor is a bit vague and nor easy to determine when talking theoretically.

by rurp 2y ago

L-four 2y ago

This is my experience it's almost always better to continue working with the existing solution as you slowly replace it's features with your own until you no longer need it. The replace everything at once approached is fraught with risk.

theshrike79 2y ago

Strangler Fig pattern works really well: https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html You split out segments of the old application and rewrite it, slowly moving traffic over - eventually slowly strangling the old application and replacing it with new parts.

hobofan 2y ago
It's a good pattern in theory, and the main route I'd personally choose most of the time. However in practice, depending on the kind of application, it can be really hard to do those gradual rewrites in practice, especially if you want to modernize by introducing new programming languages. E.g. for a legacy project on the JVM, how do you gradually shift things over to Kotlin? Or for the same project how do you go from Java to Rust? Of course you can also do that by splitting things out into REST services, but now you have to handle reliability issues of your transport layer and have to figure out how to pass large data through it and/or how to handle a barage of calls that were previously swift in-memory function calls. So in practice there are a boatload of potential challenges when doing gradual rewrites, and in my experience very few people have the expertise to pull them off in practice.
- marcosdumay 2y ago
  On the case of the OP, with a database, different pieces of software interact over the database. It's the simplest case.
JamesSwift 2y ago
Ive never seen it work in practice. Every time I see it end up with Appv1, Appv2, Appv3 all running at the same time because the new systems cant move quick enough to add new features so they get added to the older versions. But the newer systems offer unique things the older didnt. So they all coexist and never die.
- marcosdumay 2y ago
  There's something wrong with your experience, because the entire point of making a new system is that it will eventually move faster than the old one. Maybe your strangling software is still too ambitious.
- theshrike79 2y ago
  That sounds like you're trying to rewrite the whole app, NEVER do that[0]. You shouldn't end up with appv1, v2, v3. You should have appv1 along with appv1-foobarmeasurement-v2 running. Then you slowly move traffic to v2 of foobarmeasurement until it can handle 100% of the load and has all the features - then you remove that feature from appv1 completely. Then you GOTO 10 and pick a new feature to slowly strangle. [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - JamesSwift 2y ago
    My point is that if the rewrite is not able to be classified as a refactor, it wont work. It has to be entirely invisible to the user (and product side of the org). Otherwise, it is never going to be completed.
    - theshrike79 2y ago
      That's literally the point of the strangler fig pattern :) The difference between a rewrite and refactor is a bit vague and nor easy to determine when talking theoretically.