4 ms·

> it's all driven by a product mentality that favors rapid iterations and technical debt to run business experiments on customers. Which is in turn driven by

> it's all driven by a product mentality that favors rapid iterations and technical debt to run business experiments on customers. Which is in turn driven by a venture capital industry that cares only about massive growth and nothing else.

mcguire 6y ago
It's common outside the startup world, too. I think it's more to do with a disinclination to touch anything "legacy". New and shiny good, otherwise bad.
- devonkim 6y ago
  “Legacy” both works and delivers value. It also doesn’t get political visibility by making something new as a manager. Optimizing the costs of existing business lines is essentially a cost center career track in itself and is why IT people get screwed a lot and those with 90%+ of the same skills in a software development shop will get a bump in pay.
  - richiebful1 6y ago
    Yup. We have an in-house MDM solution at work that is mostly composed of stored procedures, SSIS and small C# desktop apps. It could do with some improvements, but overall it works like a charm. But we're rewriting it to use Snowflake and Kafka. With no real use case for the rewrite.
  - the_gipsy 6y ago
    There's two kinds of legacy, though. The proven, you talk about, and the tech-debt.
- _AzMoo 6y ago
  Feedback from our HR department indicates that we struggle to retain younger employees in large part because they don't want to use legacy systems.
  - rebeccaskinner 6y ago
    I think this is a huge problem, but as tempting as it is to blame the situation on "the youths" and their lack of respect for their elders or legacy code, a huge part of this is the fault of our industry and the businesses themselves. The first thing is that I think people who don't want to work on legacy systems are making a pretty rational system based on the state of the industry these days. We recruit people heavily based on whatever they've done most recently, and for a lot of people even a short stint on a legacy system can be a career ending dead-end. In very competitive markets it might not be quite as bad, but for a large swath of the market (for instance in the Midwestern US, where I'm at), a single job with a legacy technology can make you nigh unemployable doing anything else. The problem is compounded by the fact that a lot of "recent legacy" technologies simply don't pay as well as either very legacy technologies (where you might be expected to have 20+ years of experience) or hotter new technologies. Next, I think that we need to consider that, frankly, a lot of legacy code and technology sucks. New tools might have the same, or more, underlying fundamental issues, but in a lot of cases newer technology has a thicker layer of ergonomics on top, and the technologies themselves haven't ripened enough for the code smells to be noticeable, so from a day-to-day job enjoyment standpoint that somewhat lower paying job that is going to pidgeon hole you into the same boring BigCo work for the rest of your career is also going to come with a side dish of increased frustration. There's also a particular place in hell for certain types of legacy systems that really embraced the fads of their time- e.g. inheritance astronaut OOP hellscape Java applications from the late 90's, or rube-goldbergian metaprogramming funhouse ruby projects from the 2010's (I suspect the particular flavor of grotesque FP-look-alike cargo cult nonsense non-FP languages are trying to shoehorn onto poorly typed highly mutable environments is the fad that will give next decade's legacy system maintainers night sweats, but it's always hard to tell when you're in the middle of it). Finally, and I think this is the biggest factor of all, a lot of companies with big legacy systems are digging their own graves because it's not just that they have legacy systems that need to be maintained, but they are so traumatized by the difficulty of keeping those systems up and running that they have calcified beyond any ability to experiment and try anything better, so it's not just that there are legacy systems to be maintained, all new work ends up getting shoehorned into the same legacy languages, legacy frameworks, and legacy business processes, because the fact that they never managed to migrate off their 1970's COBOL applications means that everything written today has to be designed to last 40 years using 20 year old technology. If engineers who were expected to maintain the legacy systems had some leeway to also experiment with newer technologies, and to modernize some parts of the system (with the acknowledgement that not all experiments would be a success), then it might be a lot easier to keep those engineers around.
- UK-Al05 6y ago
  Depends what you mean by legacy. If you mean well written c or Java code, that is well tested and clean. Then I'd prefer to then a modern JavaScript application without tests. Legacy to me means applications that has turned into a mess with no tests. This can be a recent application or old.
  - MiroF 6y ago
    Exactly. BLAS isn't legacy to me, but that web server you wrote in an Excel macro is.
- danielnixon 6y ago
  http://themaintainers.org/blog/2019/7/30/why-do-people-neglect-maintenance http://themaintainers.org/blog/2019/7/30/why-do-people-negle...
  - greenyoda 6y ago
    Which recently had an interesting discussion on HN: https://news.ycombinator.com/item?id=21208947 https://news.ycombinator.com/item?id=21208947
- benhurmarcel 6y ago
  It's common outside the software world too. I work on aircraft design. We have people supporting legacy aircraft that were designed up to 50 years ago. I (and a lot of engineers) actively avoid those positions, and try to stick to programs that are less than 10-20 years old. It's old technology, you don't get investment to improve anything, you don't get to work with modern tools (go back to working with scanned drawings instead of CAD data for example)…

mcguire 6y ago

It's common outside the startup world, too. I think it's more to do with a disinclination to touch anything "legacy". New and shiny good, otherwise bad.

devonkim 6y ago
“Legacy” both works and delivers value. It also doesn’t get political visibility by making something new as a manager. Optimizing the costs of existing business lines is essentially a cost center career track in itself and is why IT people get screwed a lot and those with 90%+ of the same skills in a software development shop will get a bump in pay.
- richiebful1 6y ago
  Yup. We have an in-house MDM solution at work that is mostly composed of stored procedures, SSIS and small C# desktop apps. It could do with some improvements, but overall it works like a charm. But we're rewriting it to use Snowflake and Kafka. With no real use case for the rewrite.
- the_gipsy 6y ago
  There's two kinds of legacy, though. The proven, you talk about, and the tech-debt.
_AzMoo 6y ago
Feedback from our HR department indicates that we struggle to retain younger employees in large part because they don't want to use legacy systems.
- rebeccaskinner 6y ago
  I think this is a huge problem, but as tempting as it is to blame the situation on "the youths" and their lack of respect for their elders or legacy code, a huge part of this is the fault of our industry and the businesses themselves. The first thing is that I think people who don't want to work on legacy systems are making a pretty rational system based on the state of the industry these days. We recruit people heavily based on whatever they've done most recently, and for a lot of people even a short stint on a legacy system can be a career ending dead-end. In very competitive markets it might not be quite as bad, but for a large swath of the market (for instance in the Midwestern US, where I'm at), a single job with a legacy technology can make you nigh unemployable doing anything else. The problem is compounded by the fact that a lot of "recent legacy" technologies simply don't pay as well as either very legacy technologies (where you might be expected to have 20+ years of experience) or hotter new technologies. Next, I think that we need to consider that, frankly, a lot of legacy code and technology sucks. New tools might have the same, or more, underlying fundamental issues, but in a lot of cases newer technology has a thicker layer of ergonomics on top, and the technologies themselves haven't ripened enough for the code smells to be noticeable, so from a day-to-day job enjoyment standpoint that somewhat lower paying job that is going to pidgeon hole you into the same boring BigCo work for the rest of your career is also going to come with a side dish of increased frustration. There's also a particular place in hell for certain types of legacy systems that really embraced the fads of their time- e.g. inheritance astronaut OOP hellscape Java applications from the late 90's, or rube-goldbergian metaprogramming funhouse ruby projects from the 2010's (I suspect the particular flavor of grotesque FP-look-alike cargo cult nonsense non-FP languages are trying to shoehorn onto poorly typed highly mutable environments is the fad that will give next decade's legacy system maintainers night sweats, but it's always hard to tell when you're in the middle of it). Finally, and I think this is the biggest factor of all, a lot of companies with big legacy systems are digging their own graves because it's not just that they have legacy systems that need to be maintained, but they are so traumatized by the difficulty of keeping those systems up and running that they have calcified beyond any ability to experiment and try anything better, so it's not just that there are legacy systems to be maintained, all new work ends up getting shoehorned into the same legacy languages, legacy frameworks, and legacy business processes, because the fact that they never managed to migrate off their 1970's COBOL applications means that everything written today has to be designed to last 40 years using 20 year old technology. If engineers who were expected to maintain the legacy systems had some leeway to also experiment with newer technologies, and to modernize some parts of the system (with the acknowledgement that not all experiments would be a success), then it might be a lot easier to keep those engineers around.
UK-Al05 6y ago
Depends what you mean by legacy. If you mean well written c or Java code, that is well tested and clean. Then I'd prefer to then a modern JavaScript application without tests. Legacy to me means applications that has turned into a mess with no tests. This can be a recent application or old.
- MiroF 6y ago
  Exactly. BLAS isn't legacy to me, but that web server you wrote in an Excel macro is.
danielnixon 6y ago
http://themaintainers.org/blog/2019/7/30/why-do-people-neglect-maintenance http://themaintainers.org/blog/2019/7/30/why-do-people-negle...
- greenyoda 6y ago
  Which recently had an interesting discussion on HN: https://news.ycombinator.com/item?id=21208947 https://news.ycombinator.com/item?id=21208947
benhurmarcel 6y ago
It's common outside the software world too. I work on aircraft design. We have people supporting legacy aircraft that were designed up to 50 years ago. I (and a lot of engineers) actively avoid those positions, and try to stick to programs that are less than 10-20 years old. It's old technology, you don't get investment to improve anything, you don't get to work with modern tools (go back to working with scanned drawings instead of CAD data for example)…