5 ms·

I've tackled legacy systems my entire career, and there is a certain art to untying the knot of dependencies, procedures, and expectations. Not surprised at all

I've tackled legacy systems my entire career, and there is a certain art to untying the knot of dependencies, procedures, and expectations. Not surprised at all that most projects to modernize end up as smoldering craters rather than functioning systems. The legacy system trap is built on three pillars: 1. Maintenance costs are always lower than upgrade costs. It's even cheaper to pay for neither. Even if you do spend money aggressively to maintain it; every feature added, operator hired, workaround published, becomes a growing suit of armor protecting the system from replacement. 2. Management incentives are rarely aligned with the planning and sacrifices it takes to unwind technical debt. Everyone wants to cut the ribbon on the shiny new big-data/AI/ML/buzzword project, but no one wants to take responsibility for integrating it with the rusting hulks creaking along actually running day to day operations. 3. The software industry can shift paradigms enough that you end up looking to buy a new/faster horse for your buggy. And nothing fits your use case, or even offers a path out. All three in combination mean you get businesses spending obscene amounts of money on technology they can't use. It is quite satisfying to successfully maneuver an organization out of the trap. It's like solving a complex puzzle over months. Where hundreds or thousands of real people will be better off because of your team's effort.

waheoo 6y ago
> Not surprised at all that most projects to modernize end up as smoldering craters rather than functioning systems. This is because people think rewriting is a solution. It very never is. It can help, rarely, but it's never the solution, it just does a good job of hiding what the solution was. If you can't map out what is really broken in your legacy system and map out a way to refactor it to what you want then a rewrite will always fail.
- jffhn 6y ago
  >people think rewriting is a solution. It very never is. I often see this idea formulated, in this forum or in articles. >what is really broken in your legacy system. Software can be arbitrarily broken (think of only copy-pasting code from thedailywtf): http://www.cs.utexas.edu/users/dsb/CS373S/Images/softwaredesign.jpg http://www.cs.utexas.edu/users/dsb/CS373S/Images/softwaredes... I knew a legacy system where everything was broken. There were no proper data model and structures, so every computation involved multiple nested loops, making everything much slower than needed. Everything was modifiable as if it was public, so it was hard to keep things consistent. Allocation/GC and latency were through the roof, they tried to add pooling but noone could figure out where objects could be released. One of the core classes was called Banana (changed name) but actually referred to bananas or to banana trees. And the list goes on (threading, database usage, still plenty to tell). Then someone, new to both the domain and the language, stepped up to rewrite everything, which took a bit more than a month. Ten years later the core of it didn't change much, they are still building on it and it's still smooth.
  - waheoo 6y ago
    So sometimes the cost benefit of a rewrite outweighs the risk but I'd still say all those things you pointed out were the problem that needed fixing, rewrite really just fast tracked that no?
    - jffhn 6y ago
      It was rewrite "from scratch" (not refactoring), but with the previous team available to answer any question (either about the legacy code or the domain, which they knew well), which was an essential part of the success (I guess a lot of rewrite fail because they are done by new people that didn't take care to learn enough from the old system and the domain to thoroughly understand what must be done). The legacy code was too bad to make refactoring worth it, but surely not every legacy system is in that bad of a shape.
userbinator 6y ago
Management sees the new and shiny buzzwords and proclaims the effort a success, while the users see at best a system that barely works as well as the old one did, and often much worse (missing features, bugs, slowness, etc.) That's how a lot of these modernisations tend to go.
- orev 6y ago
  It’s painful to see the people who know all the hotkeys and key sequences on an old green terminal suddenly thrust into a world of mouse hunting and clicking. It makes you wonder if new things are really better.
  - edoceo 6y ago
    I worked at a bank, we had this old loan system in a terminal, all the LOs could use it fast, little hiccups but we could fix it. New web-based UI came in (~2004) and it was super customizable and was supposed to be super fast. But nobody new the new hot keys, or there were none. But it was customizable! So I spent the next few months learning this new architecture, APIs, SDKs for the crap-ware and deployed for our LOs. I got so free beers. Then I helped another bank with the same issue in their migration - that second go was like free money.
collyw 6y ago
Do you find it depressing working on crappy old systems for lengths of time? I have done enough maintenance programming that I am sick of it. It would be OK if I had the clout to say we need to refactor this part and that part, but it's always new crap slapped on to of the existing mess, or digging around for most of the day to find the line or two that needs changed to fix a bug. I guess I can just see that it's never going to improve. (Though it does sound like you actually get to improve things more than I do).

waheoo 6y ago

> Not surprised at all that most projects to modernize end up as smoldering craters rather than functioning systems. This is because people think rewriting is a solution. It very never is. It can help, rarely, but it's never the solution, it just does a good job of hiding what the solution was. If you can't map out what is really broken in your legacy system and map out a way to refactor it to what you want then a rewrite will always fail.

jffhn 6y ago
>people think rewriting is a solution. It very never is. I often see this idea formulated, in this forum or in articles. >what is really broken in your legacy system. Software can be arbitrarily broken (think of only copy-pasting code from thedailywtf): http://www.cs.utexas.edu/users/dsb/CS373S/Images/softwaredesign.jpg http://www.cs.utexas.edu/users/dsb/CS373S/Images/softwaredes... I knew a legacy system where everything was broken. There were no proper data model and structures, so every computation involved multiple nested loops, making everything much slower than needed. Everything was modifiable as if it was public, so it was hard to keep things consistent. Allocation/GC and latency were through the roof, they tried to add pooling but noone could figure out where objects could be released. One of the core classes was called Banana (changed name) but actually referred to bananas or to banana trees. And the list goes on (threading, database usage, still plenty to tell). Then someone, new to both the domain and the language, stepped up to rewrite everything, which took a bit more than a month. Ten years later the core of it didn't change much, they are still building on it and it's still smooth.
- waheoo 6y ago
  So sometimes the cost benefit of a rewrite outweighs the risk but I'd still say all those things you pointed out were the problem that needed fixing, rewrite really just fast tracked that no?
  - jffhn 6y ago
    It was rewrite "from scratch" (not refactoring), but with the previous team available to answer any question (either about the legacy code or the domain, which they knew well), which was an essential part of the success (I guess a lot of rewrite fail because they are done by new people that didn't take care to learn enough from the old system and the domain to thoroughly understand what must be done). The legacy code was too bad to make refactoring worth it, but surely not every legacy system is in that bad of a shape.

userbinator 6y ago

Management sees the new and shiny buzzwords and proclaims the effort a success, while the users see at best a system that barely works as well as the old one did, and often much worse (missing features, bugs, slowness, etc.) That's how a lot of these modernisations tend to go.

orev 6y ago
It’s painful to see the people who know all the hotkeys and key sequences on an old green terminal suddenly thrust into a world of mouse hunting and clicking. It makes you wonder if new things are really better.
- edoceo 6y ago
  I worked at a bank, we had this old loan system in a terminal, all the LOs could use it fast, little hiccups but we could fix it. New web-based UI came in (~2004) and it was super customizable and was supposed to be super fast. But nobody new the new hot keys, or there were none. But it was customizable! So I spent the next few months learning this new architecture, APIs, SDKs for the crap-ware and deployed for our LOs. I got so free beers. Then I helped another bank with the same issue in their migration - that second go was like free money.

collyw 6y ago

Do you find it depressing working on crappy old systems for lengths of time? I have done enough maintenance programming that I am sick of it. It would be OK if I had the clout to say we need to refactor this part and that part, but it's always new crap slapped on to of the existing mess, or digging around for most of the day to find the line or two that needs changed to fix a bug. I guess I can just see that it's never going to improve. (Though it does sound like you actually get to improve things more than I do).