6 ms·

Having been involved in 3+ $8-figure legacy replacement projects, this article seems to be missing business, management, and cost perspectives. In particular, "

Having been involved in 3+ $8-figure legacy replacement projects, this article seems to be missing business, management, and cost perspectives. In particular, "non-compliant with recent standards" is the least important reason to consider rewriting a working system. Often, chasing whatever is popular at the moment is the root cause of maintenance problems in the first place.

kevinmhickey 4y ago
Wish I could upvote more than once. What I call "Resume Driven Development" creates fractured architectures and reduces quality in stable systems for the sake of "the latest standard". Not the best spend for the business or users/customers.
- watwut 4y ago
  Yeah, but on the other hand the "we ignore the resume thing" makes it increasingly hard to hire and keep people. Because when tech becomes too much legacy, developers can not afford to stay there. Your employees will be selected for more passive bunch. Or you have to pay more to keep them. And I do work on project exactly like that. I am paid more then would be market rate for same position and everyone is scared we (as in seniors) are going to leave. It has advantages, not just in pay, definitely. But some of these advantages are disadvantages for the company to be frank ... like that the whole environment gets biased toward more passive and sort of sleepy. (If you are non sleepy you get pay raise, they are trying to reward it, but the force of the system is strong.) It does not result in the best spend for customer or a company.
- cratermoon 4y ago
  On the flipside, when your website only works with Internet Explorer 11, forcing your customers to keep an unsupported browser around, it's time to reconsider the aversion to keeping up with changes in the technology. It's doubly bad when your website is designed for software embedded in kiosks and the like.
  - nucleardog 4y ago
    Keeping your software up to date as dependencies age and go out of support or the platform you build on evolves is not resume driven development. There’s a business and engineering case that can easily be made for that. Of course there’s no real dictionary we can go to for this, but I’d define RDD as “chasing technology trends without business or engineering justification”. Why are we switching to JS-Framework-De-Jour? Why are we using this graphdocumentjsondistibutedimmutablelog database all of a sudden? How does this improve the business? How do see a path to a positive ROI from this decision?
    - simplotek 4y ago
      > Keeping your software up to date as dependencies age and go out of support or the platform you build on evolves is not resume driven development. There’s a business and engineering case that can easily be made for that. I'm not sure your false dichotomy holds. The definition of resume driven development is not whether there's a business case of not for a change, and the definition of legacy system is not the cost of upgrading it. > Why are we switching to JS-Framework-De-Jour? Why are we using this graphdocumentjsondistibutedimmutablelog database all of a sudden? How does this improve the business? How do see a path to a positive ROI from this decision? False dichotomies. You're assuming that not maintaining your software is free from cost or business impact, and you're assuming that switching to the latest and greatest does not bring any operational advantage.
    - cratermoon 4y ago
      I think you just said "stay up-to-date with the latest standards", but in more words.
  - JohnBooty 4y ago
    If your legacy app is incompatible with modern browsers, yeah, that's got to change. No debating that, really. But, 1. That may or may not mean a full rewrite of the app. Even in terrible old legacy apps, there usually is at least somewhat of a separation between the backend and frontend logic. 2. While not exactly uncommon, the scenario you describe is a subset of legacy apps. A lot of them work just fine, other than the fact that they're not in the latest version of the latest cool framework.
- jamesfinlayson 4y ago
  Oof, I've seen this at a previous job - lots of microservices written in the newest/most dominant language of the time: Scala, Java, .Net, Python, Javascript, Coffeescript (!), TypeScript and Go services all powering one system.
  - fbdab103 4y ago
    Clearly the answer is to rewrite them all in Rust. /s
    - hulitu 4y ago
      They are still trying to compile the rustc because the new rust project won't accept the old compiler. /s (i'm only half joking after seeing an error message like: you have rustc version 1.58.0, you need at least 1.58.1)
    - jamesfinlayson 4y ago
      Surprisingly I don't think there was any Rust - they seemed to have settled on TypeScript.
hinkley 4y ago
The sad fact of software projects is that some part of the work is always a bit of bribery to keep skilled labor engaged. You’re always throwing them bones, letting them work on a few things that don’t really need to be done but make them happy. That’s lost sometimes when I’m lamenting NIH or wheel reinvention, but it’s a matter of degrees. Let them have one big thing and a bunch of small things. Companies go off the rails and get trashed talked when they clamp down and go for zero fun, 100% financially justifiable task lists. As a tech ages out you can’t find anyone good to work on it. And when you make them, morale craters.
- djbusby 4y ago
  From my perspective, there's loads of this legacy/boring crap (lots of PHP&Rails). As a "old" coder, I love those legacy apps that folk can't/don't give to their internal team - it becomes consulting work for me :)
  - mattlutze 4y ago
    That's the trouble though isn't it—leaving it to mature gracefully in the cellar gets you to a point where only an expert somilier in that particular varietal knows really what to do with it, and you pay through the nose for their knowledge.
  - pmarreck 4y ago
    any tips on how to get started here? I have plenty of past Rails experience and although I'd prefer rewriting the stack endpoint by endpoint in something like Phoenix, I'd probably be amenable to other kinds of work yet staying in the Ruby ecosystem
    - djbusby 4y ago
      I just kept telling my network to hand over their legacy projects. I'm not in the resume builder phase of the career. And folk (managers and devs) on the legacy project are happy to hand it over (provided they trust you). Helps all of their OKRs. And sometimes you get landed a fun legacy one where you have to rebuild some binary by de-compiling first (thanks for not stripping the binary previous long-gone dev) and then spend days re-factoring it to work with updated AT commands on the new hardware. And nobody's rushing you, cause you're like the only one doing it; and finding another person to even WANT to do this is $HARDWORK. I'm still out here doing VB6/VBA, Perl as well.
didgetmaster 4y ago
Another problem is that too much software these days is built like the rest of our disposable society. We don't build things to last with a solid architecture that can withstand major modifications. Instead we throw together something that just meets an immediate need with minimal commitment of time and money. Little thought is given to how the project will react when business needs change down the road. The saying 'penny-wise but pound-foolish' applies in many cases.
- eastbound 4y ago
  The comment just above you says that if we build things to last, we don’t find anyone to work on that old tech after the initial 5 years. The software industry is stuck in a rolling thunder: We engineer things to last for 5 years, precisely because programmers expect to have to prepare their resume for the 5-year-newer-tech. Only Linux and Postgres beat this doom.
- wongarsu 4y ago
  Maybe that's an overreaction to the enterprise Java applications, which often introduce lots of needless complexity in the accept to incorporate flexibility for future changes
  - hulitu 4y ago
    I tried to compile seamonkey and firefox from source. They both failed at the rustc compiler checking. Apparently the trend in SW development is to compile one moving target with another moving target.
  - pjmlp 4y ago
    Kubernetes with WASM containers say hello.

kevinmhickey 4y ago

Wish I could upvote more than once. What I call "Resume Driven Development" creates fractured architectures and reduces quality in stable systems for the sake of "the latest standard". Not the best spend for the business or users/customers.

watwut 4y ago
Yeah, but on the other hand the "we ignore the resume thing" makes it increasingly hard to hire and keep people. Because when tech becomes too much legacy, developers can not afford to stay there. Your employees will be selected for more passive bunch. Or you have to pay more to keep them. And I do work on project exactly like that. I am paid more then would be market rate for same position and everyone is scared we (as in seniors) are going to leave. It has advantages, not just in pay, definitely. But some of these advantages are disadvantages for the company to be frank ... like that the whole environment gets biased toward more passive and sort of sleepy. (If you are non sleepy you get pay raise, they are trying to reward it, but the force of the system is strong.) It does not result in the best spend for customer or a company.
cratermoon 4y ago
On the flipside, when your website only works with Internet Explorer 11, forcing your customers to keep an unsupported browser around, it's time to reconsider the aversion to keeping up with changes in the technology. It's doubly bad when your website is designed for software embedded in kiosks and the like.
- nucleardog 4y ago
  Keeping your software up to date as dependencies age and go out of support or the platform you build on evolves is not resume driven development. There’s a business and engineering case that can easily be made for that. Of course there’s no real dictionary we can go to for this, but I’d define RDD as “chasing technology trends without business or engineering justification”. Why are we switching to JS-Framework-De-Jour? Why are we using this graphdocumentjsondistibutedimmutablelog database all of a sudden? How does this improve the business? How do see a path to a positive ROI from this decision?
  - simplotek 4y ago
    > Keeping your software up to date as dependencies age and go out of support or the platform you build on evolves is not resume driven development. There’s a business and engineering case that can easily be made for that. I'm not sure your false dichotomy holds. The definition of resume driven development is not whether there's a business case of not for a change, and the definition of legacy system is not the cost of upgrading it. > Why are we switching to JS-Framework-De-Jour? Why are we using this graphdocumentjsondistibutedimmutablelog database all of a sudden? How does this improve the business? How do see a path to a positive ROI from this decision? False dichotomies. You're assuming that not maintaining your software is free from cost or business impact, and you're assuming that switching to the latest and greatest does not bring any operational advantage.
  - cratermoon 4y ago
    I think you just said "stay up-to-date with the latest standards", but in more words.
- JohnBooty 4y ago
  If your legacy app is incompatible with modern browsers, yeah, that's got to change. No debating that, really. But, 1. That may or may not mean a full rewrite of the app. Even in terrible old legacy apps, there usually is at least somewhat of a separation between the backend and frontend logic. 2. While not exactly uncommon, the scenario you describe is a subset of legacy apps. A lot of them work just fine, other than the fact that they're not in the latest version of the latest cool framework.
jamesfinlayson 4y ago
Oof, I've seen this at a previous job - lots of microservices written in the newest/most dominant language of the time: Scala, Java, .Net, Python, Javascript, Coffeescript (!), TypeScript and Go services all powering one system.
- fbdab103 4y ago
  Clearly the answer is to rewrite them all in Rust. /s
  - hulitu 4y ago
    They are still trying to compile the rustc because the new rust project won't accept the old compiler. /s (i'm only half joking after seeing an error message like: you have rustc version 1.58.0, you need at least 1.58.1)
  - jamesfinlayson 4y ago
    Surprisingly I don't think there was any Rust - they seemed to have settled on TypeScript.

hinkley 4y ago

The sad fact of software projects is that some part of the work is always a bit of bribery to keep skilled labor engaged. You’re always throwing them bones, letting them work on a few things that don’t really need to be done but make them happy. That’s lost sometimes when I’m lamenting NIH or wheel reinvention, but it’s a matter of degrees. Let them have one big thing and a bunch of small things. Companies go off the rails and get trashed talked when they clamp down and go for zero fun, 100% financially justifiable task lists. As a tech ages out you can’t find anyone good to work on it. And when you make them, morale craters.

djbusby 4y ago
From my perspective, there's loads of this legacy/boring crap (lots of PHP&Rails). As a "old" coder, I love those legacy apps that folk can't/don't give to their internal team - it becomes consulting work for me :)
- mattlutze 4y ago
  That's the trouble though isn't it—leaving it to mature gracefully in the cellar gets you to a point where only an expert somilier in that particular varietal knows really what to do with it, and you pay through the nose for their knowledge.
- pmarreck 4y ago
  any tips on how to get started here? I have plenty of past Rails experience and although I'd prefer rewriting the stack endpoint by endpoint in something like Phoenix, I'd probably be amenable to other kinds of work yet staying in the Ruby ecosystem
  - djbusby 4y ago
    I just kept telling my network to hand over their legacy projects. I'm not in the resume builder phase of the career. And folk (managers and devs) on the legacy project are happy to hand it over (provided they trust you). Helps all of their OKRs. And sometimes you get landed a fun legacy one where you have to rebuild some binary by de-compiling first (thanks for not stripping the binary previous long-gone dev) and then spend days re-factoring it to work with updated AT commands on the new hardware. And nobody's rushing you, cause you're like the only one doing it; and finding another person to even WANT to do this is $HARDWORK. I'm still out here doing VB6/VBA, Perl as well.

didgetmaster 4y ago

Another problem is that too much software these days is built like the rest of our disposable society. We don't build things to last with a solid architecture that can withstand major modifications. Instead we throw together something that just meets an immediate need with minimal commitment of time and money. Little thought is given to how the project will react when business needs change down the road. The saying 'penny-wise but pound-foolish' applies in many cases.

eastbound 4y ago
The comment just above you says that if we build things to last, we don’t find anyone to work on that old tech after the initial 5 years. The software industry is stuck in a rolling thunder: We engineer things to last for 5 years, precisely because programmers expect to have to prepare their resume for the 5-year-newer-tech. Only Linux and Postgres beat this doom.
wongarsu 4y ago
Maybe that's an overreaction to the enterprise Java applications, which often introduce lots of needless complexity in the accept to incorporate flexibility for future changes
- hulitu 4y ago
  I tried to compile seamonkey and firefox from source. They both failed at the rustc compiler checking. Apparently the trend in SW development is to compile one moving target with another moving target.
- pjmlp 4y ago
  Kubernetes with WASM containers say hello.