4 ms·

Yes, legacy systems cost a lot to replace, but continuous development over 20 years isn’t exactly cheap either. Hardly anyone talks about that though. And let’

Yes, legacy systems cost a lot to replace, but continuous development over 20 years isn’t exactly cheap either. Hardly anyone talks about that though. And let’s be real, if a system is non-legacy it’s likely being completely rewritten every 5-10 years anyway. Not many active codebases have 10 year old code still running.

bluGill 6y ago
10 year old code would be considered very new where I work. I know for a fact code I wrote 10 years ago is still the heart of our system (with very few changes). I know of code that someone else wrote 30 years ago that is still in use, getting that code tested is very important so we can confidently make changes for the next product that will use it. A few years back we started an effort to rewrite some old C code into a modern system with formal proofs of correctness. That was given up because the new improved process turned out to be 3x more expensive to write new code vs new code in the old process. (formal proofs were the reason to use the new process, but not the reason it was 3x more expensive. I'm not allowed to comment beyond this so don't ask...)
- kjs3 6y ago
  If you book an airline ticket, odds are under the hood you're hitting an IBM TPF application (prolly PARS/IPARS). When I was involved in that world 20 some-odd years ago the programmers would regularly show me files with 'last modified' in the 80's and 90's. These aren't things that someone casually modifies, and I would expect you'd find an awful lot of the same even now.
nine_k 6y ago
I'm typing this from a legacy browser (first released 18 years ago) running on a legacy OS (first released 29 years ago, a rehash of a design from 50+ years), and will switch to my legacy editor (first released 44 years ago) to continue work.
- coddle-hark 6y ago
  Firefox, Linux, and vi aren't "legacy" software by any reasonable definition of the word, so no you're not.
  - nine_k 6y ago
    Emacs; vi is older. But all of them still contain crucial central parts that have been created decades ago, and famously have not been redone from scratch in their history, unlike, say, Windows or vim. I don't see what is the principal difference between these pieces of software, and some COBOL-based accounting packages still doing heavy lifting in s bank, while being actively maintained and even receiving new features.
    - Jtsummers 6y ago
      Legacy systems aren't just old. Old systems that are maintained aren't the legacy systems that create problems, and really aren't legacy systems at all (just old). It's the old systems that "just work" until they don't. Where they run on old hardware, and the compiler is possibly on something even older. You can't port them to a new system because you may not have a compiler or even the source code. Or the source code is heavily dependent on the original physical hardware. Maybe it runs in a VM, if it was on an IBM mainframe it probably does. But that doesn't fix the problem of old code that can't be easily altered at this point in time. I like Michael Feathers' definition of legacy code being code without tests. But it's not just tests, it's comprehensibility and (to a lesser extent) portability. Tests help to make a system comprehensible and portable. Since architecting for testing requires better modularity which makes things both more portable and more comprehensible in most cases. Portability means proper abstraction over the hardware or other things so that the core logic is separable. Imagine if the IRS's tax system were written in this way, where the hard-to-port part would be the interface with databases and networks, but the core part would be easily portable (or more easily portable) to another OS because it'd be properly separated. We could port that core to another system and change how it gets called more easily. But if you tied your software to a specific DB or a specific storage medium (like it has to be a tape drive, or something that behaves like one) you've reduced portability, and created the start of a legacy system.
saiya-jin 6y ago
Those 20 years weren't about current functionality, but tons of changes reflecting how business requirements were changing. New system from the scratch in the same technology would be very cheap (given there are folks around who still know original language/platform). System being completely rewritten - I can't agree on that one either. Some, in some companies do, most don't. I personally manage quite a few of those and there isn't budget for costly migration experiments if things work. Working in one of the biggest global banks in Switzerland. What works is if ie OS/browser that is absolutely required isn't supported anymore and there is no way around it. There are very few cases where the approach 'if it isn't broken don't fix it' isn't the best approach for the company. But good luck trying to explain it to devs/teams who want to try new things (basically at the cost of employer, I don't blame them but it is what it is).
zaphar 6y ago
The primary money making code where I work is well over 10 years old and still going strong. Still being maintained and improved. Still getting features added.

bluGill 6y ago

10 year old code would be considered very new where I work. I know for a fact code I wrote 10 years ago is still the heart of our system (with very few changes). I know of code that someone else wrote 30 years ago that is still in use, getting that code tested is very important so we can confidently make changes for the next product that will use it. A few years back we started an effort to rewrite some old C code into a modern system with formal proofs of correctness. That was given up because the new improved process turned out to be 3x more expensive to write new code vs new code in the old process. (formal proofs were the reason to use the new process, but not the reason it was 3x more expensive. I'm not allowed to comment beyond this so don't ask...)

kjs3 6y ago
If you book an airline ticket, odds are under the hood you're hitting an IBM TPF application (prolly PARS/IPARS). When I was involved in that world 20 some-odd years ago the programmers would regularly show me files with 'last modified' in the 80's and 90's. These aren't things that someone casually modifies, and I would expect you'd find an awful lot of the same even now.

nine_k 6y ago

I'm typing this from a legacy browser (first released 18 years ago) running on a legacy OS (first released 29 years ago, a rehash of a design from 50+ years), and will switch to my legacy editor (first released 44 years ago) to continue work.

coddle-hark 6y ago
Firefox, Linux, and vi aren't "legacy" software by any reasonable definition of the word, so no you're not.
- nine_k 6y ago
  Emacs; vi is older. But all of them still contain crucial central parts that have been created decades ago, and famously have not been redone from scratch in their history, unlike, say, Windows or vim. I don't see what is the principal difference between these pieces of software, and some COBOL-based accounting packages still doing heavy lifting in s bank, while being actively maintained and even receiving new features.
  - Jtsummers 6y ago
    Legacy systems aren't just old. Old systems that are maintained aren't the legacy systems that create problems, and really aren't legacy systems at all (just old). It's the old systems that "just work" until they don't. Where they run on old hardware, and the compiler is possibly on something even older. You can't port them to a new system because you may not have a compiler or even the source code. Or the source code is heavily dependent on the original physical hardware. Maybe it runs in a VM, if it was on an IBM mainframe it probably does. But that doesn't fix the problem of old code that can't be easily altered at this point in time. I like Michael Feathers' definition of legacy code being code without tests. But it's not just tests, it's comprehensibility and (to a lesser extent) portability. Tests help to make a system comprehensible and portable. Since architecting for testing requires better modularity which makes things both more portable and more comprehensible in most cases. Portability means proper abstraction over the hardware or other things so that the core logic is separable. Imagine if the IRS's tax system were written in this way, where the hard-to-port part would be the interface with databases and networks, but the core part would be easily portable (or more easily portable) to another OS because it'd be properly separated. We could port that core to another system and change how it gets called more easily. But if you tied your software to a specific DB or a specific storage medium (like it has to be a tape drive, or something that behaves like one) you've reduced portability, and created the start of a legacy system.

saiya-jin 6y ago

Those 20 years weren't about current functionality, but tons of changes reflecting how business requirements were changing. New system from the scratch in the same technology would be very cheap (given there are folks around who still know original language/platform). System being completely rewritten - I can't agree on that one either. Some, in some companies do, most don't. I personally manage quite a few of those and there isn't budget for costly migration experiments if things work. Working in one of the biggest global banks in Switzerland. What works is if ie OS/browser that is absolutely required isn't supported anymore and there is no way around it. There are very few cases where the approach 'if it isn't broken don't fix it' isn't the best approach for the company. But good luck trying to explain it to devs/teams who want to try new things (basically at the cost of employer, I don't blame them but it is what it is).

zaphar 6y ago

The primary money making code where I work is well over 10 years old and still going strong. Still being maintained and improved. Still getting features added.