5 ms·

Incremental rewrites assume that your framework of choice is still supported. In my experience, I would say 75% of the time someone is considering a rewrite, it

by mbesto 7y ago

Incremental rewrites assume that your framework of choice is still supported. In my experience, I would say 75% of the time someone is considering a rewrite, it's because their framework of choice is out of date, which makes it impossible to modify old code.

dragonwriter 7y ago
> Incremental rewrites assume that your framework of choice is still supported You mean the one for the legacy? (Which I wouldn't call the framework of choice, since it's inherited, the new one is chosen...) Sure it requires that the legacy code is, at least internally, supported or at least supportable, and sometimes that's not the case. Though on larger production systems, letting them get to a completely unsupported state is rare, and those are the systems where the choice between big-banf rewrite, strangler, and a more free incremental replacement are most consequential, IMO. If nothing other than a big-banf rewrite is possible, there's not a choice, much less a consequential one.
- mbesto 7y ago
  When I hear "legacy application", I basically assume the framework used is outdated/unsupported. That's my point, you can't incrementally rewrite that because you'd be rebuilding on a burning platform. Example - you wrote your app in a custom PHP using PHP 5.6 and you're doing a rewrite in PHP v7 in Laravel.
  - dragonwriter 7y ago
    > When I hear "legacy application", I basically assume the framework used is outdated/unsupported. That's often the case, but the app itself is usually actively (if lightly, sometimes, because the cost of change is high and there is a lack of skilled maintainance personnel) even if the underlying platform is outdated and possibly even out of support (and in some cases long abandoned by the vendor.) > That's my point, you can't incrementally rewrite that because you'd be rebuilding on a burning platform. You absolutely can maintain software on an outdated and, often, unsupported platform (the latter can sometimes be a licensing problem, as you may not continue to have the legal right to use it.)
    - mbesto 7y ago
      > You absolutely can maintain software on an outdated and, often, unsupported platform Huh? I mean yes you can technically continue to use an outdated framework, but what do you do when there is CVE identified and someone exploits it? Do you just sit on your hands and wait until you can upgrade the whole framework months later? There are explicit risks associated with continued use of an outdated and unsupported framework, so why anyone would continue to build on a burning platform is beyond me...
      - dragonwriter 7y ago
        > Huh? I mean yes you can technically continue to use an outdated framework, but what do you do when there is CVE identified and someone exploits Technically, you can do a big bang rewrite, but they fail at a very high rate on significant systems—and you're still using the unsupported system while you do the big bang rewrite, and quite possibly after it fails, so you even in the best case you haven't eliminated the problem you point to with doing an incremental rewrite. So, the basic problem exists either way. Incremental rewrites (strangler or otherwise) prioritizing the highest-risk components for earliest replacement is one plausible risk-mitigation strategy, but the right choice is going to depend on project details. When you eliminate real options because of fake “you can't do that” considerations, you increase the risk of choosing a suboptimal approach because you preemptively discarded the least-bad solution.
        mbesto 7y ago
        > Incremental rewrites You keep using this term and I don't think you know what it means. The Strangler pattern IS an incremental rewrite. You've suggested that it's possible to introduce incremental rewrites to old code and all I was clarifying is that by refactoring code written in an old framework (e.g. PHP 5.6) does nothing to eliminate technical debt (adds to it, in fact). The Strangler pattern is most often used when you want to switch languages (e.g. Java -> Rails) or when an older paradigm doesn't have a straight migration path (e.g. WebForms -> .NET MVC). The new code using the new framework essentially strangles the old code. For the record, I've advised over 100+ software companies, which I would say about 60%+/- of them are experiencing some type of major rewrite and of those, 9/10 are because they simply can't upgrade an outdated/unsupported/poorly architecture software framework. Trying to refactor an unsupported framework is simply not an option. You (1) either migrate it to the latest (if possible) and refactor over time, (2) strangle it with the new framework, or (3) rewrite it. That's it. Every other topic discussed is simply just one of those but semantically wrapped in some engineering jargon or nuance. This is all consistent with the examples here: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/ https://paulhammant.com/2013/07/14/legacy-application-strang... - C++ -> Java Spring - Powerbuilder/Sybase -> Swing - VB6 -> .NET - Java -> Rails - Java/Swing -> Rails The real world is FULL of these. I've seen many of them first hand. The rewrites you hear about in the "SV world" are either superfluous CTOs who are misguided into thinking they need to, for example, rewrite their Rails 4.2 app in Node because they think it'll get them more users, or represent real engineering feats that truly "blitzscale" startups entertain to maintain business continuity (Twitter's migration from Rails to Scala comes to mind).
detaro 7y ago
Things need to be more than "out of date" to be impossible to modify. What technologies would you label that way?
- mbesto 7y ago
  What do you mean? Technically speaking, you can build software on an outdated and unsupported framework, sure. But why on earth would you, for example, continue building your software on PHP 5.6 (EOL Jan 2019) when anytime a CVE is identified, you're basically SOL in being able to patch it.
  - detaro 7y ago
    Sure, you shouldn't just stick with the old and add features. You should focus an incremental rewrite to bring you closer to a switch to something supported early (e.g. dumping dependencies that won't migrate with you, preparing the code base for a quick conversion of incompatible language features, ...). Only few technologies are such dead-ends that isn't possible. But once it's too late no migration strategy rids you of the old codebase and it's environment now. With the full rewrite you need to maintain and run it until that's done. With the strangler the old code still runs until it is replaced.
    - mbesto 7y ago
      I'm so confused. What are you suggesting that's any different from what I said?
      - detaro 7y ago
        Apologies, then I must have misunderstood your original comment.
        mbesto 7y ago
        All good!
- 7y ago

by mbesto 7y ago

dragonwriter 7y ago

> Incremental rewrites assume that your framework of choice is still supported You mean the one for the legacy? (Which I wouldn't call the framework of choice, since it's inherited, the new one is chosen...) Sure it requires that the legacy code is, at least internally, supported or at least supportable, and sometimes that's not the case. Though on larger production systems, letting them get to a completely unsupported state is rare, and those are the systems where the choice between big-banf rewrite, strangler, and a more free incremental replacement are most consequential, IMO. If nothing other than a big-banf rewrite is possible, there's not a choice, much less a consequential one.

mbesto 7y ago
When I hear "legacy application", I basically assume the framework used is outdated/unsupported. That's my point, you can't incrementally rewrite that because you'd be rebuilding on a burning platform. Example - you wrote your app in a custom PHP using PHP 5.6 and you're doing a rewrite in PHP v7 in Laravel.
- dragonwriter 7y ago
  > When I hear "legacy application", I basically assume the framework used is outdated/unsupported. That's often the case, but the app itself is usually actively (if lightly, sometimes, because the cost of change is high and there is a lack of skilled maintainance personnel) even if the underlying platform is outdated and possibly even out of support (and in some cases long abandoned by the vendor.) > That's my point, you can't incrementally rewrite that because you'd be rebuilding on a burning platform. You absolutely can maintain software on an outdated and, often, unsupported platform (the latter can sometimes be a licensing problem, as you may not continue to have the legal right to use it.)
  - mbesto 7y ago
    > You absolutely can maintain software on an outdated and, often, unsupported platform Huh? I mean yes you can technically continue to use an outdated framework, but what do you do when there is CVE identified and someone exploits it? Do you just sit on your hands and wait until you can upgrade the whole framework months later? There are explicit risks associated with continued use of an outdated and unsupported framework, so why anyone would continue to build on a burning platform is beyond me...
    - dragonwriter 7y ago
      > Huh? I mean yes you can technically continue to use an outdated framework, but what do you do when there is CVE identified and someone exploits Technically, you can do a big bang rewrite, but they fail at a very high rate on significant systems—and you're still using the unsupported system while you do the big bang rewrite, and quite possibly after it fails, so you even in the best case you haven't eliminated the problem you point to with doing an incremental rewrite. So, the basic problem exists either way. Incremental rewrites (strangler or otherwise) prioritizing the highest-risk components for earliest replacement is one plausible risk-mitigation strategy, but the right choice is going to depend on project details. When you eliminate real options because of fake “you can't do that” considerations, you increase the risk of choosing a suboptimal approach because you preemptively discarded the least-bad solution.
      - mbesto 7y ago
        > Incremental rewrites You keep using this term and I don't think you know what it means. The Strangler pattern IS an incremental rewrite. You've suggested that it's possible to introduce incremental rewrites to old code and all I was clarifying is that by refactoring code written in an old framework (e.g. PHP 5.6) does nothing to eliminate technical debt (adds to it, in fact). The Strangler pattern is most often used when you want to switch languages (e.g. Java -> Rails) or when an older paradigm doesn't have a straight migration path (e.g. WebForms -> .NET MVC). The new code using the new framework essentially strangles the old code. For the record, I've advised over 100+ software companies, which I would say about 60%+/- of them are experiencing some type of major rewrite and of those, 9/10 are because they simply can't upgrade an outdated/unsupported/poorly architecture software framework. Trying to refactor an unsupported framework is simply not an option. You (1) either migrate it to the latest (if possible) and refactor over time, (2) strangle it with the new framework, or (3) rewrite it. That's it. Every other topic discussed is simply just one of those but semantically wrapped in some engineering jargon or nuance. This is all consistent with the examples here: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/ https://paulhammant.com/2013/07/14/legacy-application-strang... - C++ -> Java Spring - Powerbuilder/Sybase -> Swing - VB6 -> .NET - Java -> Rails - Java/Swing -> Rails The real world is FULL of these. I've seen many of them first hand. The rewrites you hear about in the "SV world" are either superfluous CTOs who are misguided into thinking they need to, for example, rewrite their Rails 4.2 app in Node because they think it'll get them more users, or represent real engineering feats that truly "blitzscale" startups entertain to maintain business continuity (Twitter's migration from Rails to Scala comes to mind).

detaro 7y ago

Things need to be more than "out of date" to be impossible to modify. What technologies would you label that way?

mbesto 7y ago
What do you mean? Technically speaking, you can build software on an outdated and unsupported framework, sure. But why on earth would you, for example, continue building your software on PHP 5.6 (EOL Jan 2019) when anytime a CVE is identified, you're basically SOL in being able to patch it.
- detaro 7y ago
  Sure, you shouldn't just stick with the old and add features. You should focus an incremental rewrite to bring you closer to a switch to something supported early (e.g. dumping dependencies that won't migrate with you, preparing the code base for a quick conversion of incompatible language features, ...). Only few technologies are such dead-ends that isn't possible. But once it's too late no migration strategy rids you of the old codebase and it's environment now. With the full rewrite you need to maintain and run it until that's done. With the strangler the old code still runs until it is replaced.
  - mbesto 7y ago
    I'm so confused. What are you suggesting that's any different from what I said?
    - detaro 7y ago
      Apologies, then I must have misunderstood your original comment.
      - mbesto 7y ago
        All good!
7y ago