6 ms·

> Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of

> Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities This was an actual pitch point to switch language and stack in a previous company. At some point the CTO+HR dept made the calculation that it would cost less in the long term to rewrite our services in a new language and bring in cheap/abundant devs, than to bring in more people familiar with the current stack and continue scaling it, as those had an higher average salary on the market.

Trasmatta 5y ago
This also just came up recently at my company, that we should maybe rewrite because our technology hurts us in terms of recruiting... I'm not sure the people considering that realize how costly that decision would be. Is it really worth the millions and millions it would cost to rewrite into something considered more sexy? Probably multiple years of incremental work to get it done, and a massive hit to developer productivity and maintenance costs along the way. I'm also reminded of when Twitter claimed that it was Rails' fault that they didn't have better moderation tools. One of the most hilarious excuses I've ever heard.
- makeitdouble 5y ago
  The not so hidden assumption that came with the pitch was that a bunch of the well-paid senior staff would leave for greener pastures (they wouldn't stick to maintaining a "legacy" stack). The savings were coming from both incoming and outgoing flow...
  - Trasmatta 5y ago
    Or alternatively, there are some senior staff that are just plain bored with the current stack, and want the chance to play with something more exciting to them. Both are possibilities, depending on where the idea is originating.
    - travisgriggs 5y ago
      I’m guilty of doing this at my current company. I am a creative builder. There’s something inspiring about building things in a new format, the same way an artist might explore art in a new medium. I get frustrated with the parts of the company that use “technology X” because it’s a “core competency.” I’d be more accepting of this argument if I didn’t notice a strong correlation between proponents of this strategy and people who often do bare minimum maintenance, purely market request driven, nothing inspiring or innovative or game changing. Then competitor does something cool next door and tue blame game starts as the pink slips issue. Evolve or die. There is of course the flip side of this coin, and the yen-yang of balance is what makes for the best strategy.
      - rmoriz 5y ago
        >Evolve or die. The value in one's application is the domain specific part (the product). By switching the tools, which almost always are created outside of one's organization, you don't enhance your product. With each rewrite you risk the advantages of your existing product and you will still be a consumer of third party language/framework, just another one yet without experience.
- p_l 5y ago
  Well, it depends on your goals. Recruiting cheaper programmers will probably look nice on immediate results for a time, assuming the rewrite progresses well. Whether the flood of bootcamp grads which, thanks to law of large numbers, will also contain a lot more bad choices and overwhelm your filtering ability, be actually good stewards for continued existence of things possibly critical to the business... is a completely different thing.
  - Trasmatta 5y ago
    > Recruiting cheaper programmers will probably look nice on immediate results for a time, assuming the rewrite progresses well. Possibly, but on the other hand, "adding more developers to a late project just makes it more late". It all just feels like a colossal rathole to me. I'm feeling exhausted just thinking about it.
    - nikanj 5y ago
      Possibly, but on the other hand, management usually sees this as a success story for HR ("Managed to fill every spot in days"), and a failure on the dev team ("The project slipped by months, despite getting all the people they asked for")
- winternett 5y ago
  Anything that was reliable in up-time suddenly becomes legacy I guess. It also forces Cloud Service Providers to pivot to supporting the new flashy solutions, and suddenly "old faithful solution" ends up looking like the old frail man in the corner. It's a never ending lesson in building sand castles... I think Silicon Valley illustrated this concept best. Just posted this clip a day ago to my twitter, so I too have felt the searing pain of being an IT architect and watching the right solution decisions get snowplowed - https://www.youtube.com/watch?v=ySDX02WD0og https://www.youtube.com/watch?v=ySDX02WD0og
- Moru 5y ago
  I bought a gps app several years ago after testing it out on my phone. It had everything I wanted and was fast and smooth on my phone. Next year I wanted to use it for a long trip but then it was updated, they had rewritten it from scratch. Most of the functions I liked were gone and the thing was slow like I have never seen. Battery drain was big, the phone got scorching hot. Now after 8 years it still does not have all the functions it had when I bought it and it's still too slow to be used even after changing to faster phone a couple of times. And still people are so fast to convert to latest frameworks and do complete rewrites. Most of the time recreating bugs they thought they got rid of many years ago. Or just make loads of new bugs. Or make it so slow on old phones that it can't be used any more.
  - overflow897 5y ago
    Evernote is pretty much ruined for me because of this. From a lovely, snappy native app to an electron monstrosity that's slow and barely usable. Lucky for them their only competitor is Notion, another slow js app.
  - cudgy 5y ago
    Probably they decided to ditch their native app for a cross-platform web based resource hog.
    - Moru 5y ago
      Yeah, think they said it was an electron app now.
- HWR_14 5y ago
  You left out the most important part. Sexy is a moving target. By the time your multiple years of incremental work moving it over are done, the new technology will be old and unsexy. Heck, in some cases the very fact that you(uncool company) use it will cause it to be unsexy.
- akagusu 5y ago
  One interesting outcome of Twitter's claim was other startups moving away from Rails towards other stacks.
ggm 5y ago
In my not infrequent rants inside the company I work for, I stand on one side of a major philosophical disagreement about old languages. The proponents of "keep coding in this old language" are also the people who want to retain the 5-10 year old OS, DB, and assumptions about external threat models and technical debt. Suffice to say nobody I ask outside of this company wants to adopt this model: Retained old platforms plagues the banking and finance sector. A 1950s OS called LEO was emulated by a 1960s OS called GEORGE which in turn is emulated by 1970s and 1980s ICL/Fujitsu mainframes, all because the core finance app is in COBOL and two greybeards per bank are on $mil to keep it working...
- scarygliders 5y ago
  Banking... - Does that COBOL code do the thing(s) it's supposed to in a reliable and 100% predictable way? My guess is : Yes it does. So let's go down your path. You rewrite that COBOL program using your hot new recent language of choice. How many new bugs will be introduced? What other risks are there in this new language; CVEs? RCEs? Simple coding bugs which could cost that bank millions/billions/trillions - or just as bad, the bank's customers their savings/livelihoods? Which New Hotness language would you rewrite that crusty old COBOL application in? Rust? [0] Golang? [1] Something else? There are times when it's better to leave the New Hotness to some new application rather than trying to replace a known reliable/predictable system with New Hotness. Especially for banking. [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=golang https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=golang
  - Moto7451 5y ago
    Every couple of years someone at work rewrites the email sending code in a new sexy language and reimplements the same 7 bit encoding bugs as well as other subtle email encoding issues. This happens even with ample documentation and code comments about why specific conditionals are set.
    - SenHeng 5y ago
WrtCdEvrydy 5y ago
I've been through this multiple times. By the time you have something that is as good as what you had before the rewrite in the new programming language, the cost reductions will not be worth it.

Trasmatta 5y ago

This also just came up recently at my company, that we should maybe rewrite because our technology hurts us in terms of recruiting... I'm not sure the people considering that realize how costly that decision would be. Is it really worth the millions and millions it would cost to rewrite into something considered more sexy? Probably multiple years of incremental work to get it done, and a massive hit to developer productivity and maintenance costs along the way. I'm also reminded of when Twitter claimed that it was Rails' fault that they didn't have better moderation tools. One of the most hilarious excuses I've ever heard.

makeitdouble 5y ago
The not so hidden assumption that came with the pitch was that a bunch of the well-paid senior staff would leave for greener pastures (they wouldn't stick to maintaining a "legacy" stack). The savings were coming from both incoming and outgoing flow...
- Trasmatta 5y ago
  Or alternatively, there are some senior staff that are just plain bored with the current stack, and want the chance to play with something more exciting to them. Both are possibilities, depending on where the idea is originating.
  - travisgriggs 5y ago
    I’m guilty of doing this at my current company. I am a creative builder. There’s something inspiring about building things in a new format, the same way an artist might explore art in a new medium. I get frustrated with the parts of the company that use “technology X” because it’s a “core competency.” I’d be more accepting of this argument if I didn’t notice a strong correlation between proponents of this strategy and people who often do bare minimum maintenance, purely market request driven, nothing inspiring or innovative or game changing. Then competitor does something cool next door and tue blame game starts as the pink slips issue. Evolve or die. There is of course the flip side of this coin, and the yen-yang of balance is what makes for the best strategy.
    - rmoriz 5y ago
      >Evolve or die. The value in one's application is the domain specific part (the product). By switching the tools, which almost always are created outside of one's organization, you don't enhance your product. With each rewrite you risk the advantages of your existing product and you will still be a consumer of third party language/framework, just another one yet without experience.
p_l 5y ago
Well, it depends on your goals. Recruiting cheaper programmers will probably look nice on immediate results for a time, assuming the rewrite progresses well. Whether the flood of bootcamp grads which, thanks to law of large numbers, will also contain a lot more bad choices and overwhelm your filtering ability, be actually good stewards for continued existence of things possibly critical to the business... is a completely different thing.
- Trasmatta 5y ago
  > Recruiting cheaper programmers will probably look nice on immediate results for a time, assuming the rewrite progresses well. Possibly, but on the other hand, "adding more developers to a late project just makes it more late". It all just feels like a colossal rathole to me. I'm feeling exhausted just thinking about it.
  - nikanj 5y ago
    Possibly, but on the other hand, management usually sees this as a success story for HR ("Managed to fill every spot in days"), and a failure on the dev team ("The project slipped by months, despite getting all the people they asked for")
winternett 5y ago
Anything that was reliable in up-time suddenly becomes legacy I guess. It also forces Cloud Service Providers to pivot to supporting the new flashy solutions, and suddenly "old faithful solution" ends up looking like the old frail man in the corner. It's a never ending lesson in building sand castles... I think Silicon Valley illustrated this concept best. Just posted this clip a day ago to my twitter, so I too have felt the searing pain of being an IT architect and watching the right solution decisions get snowplowed - https://www.youtube.com/watch?v=ySDX02WD0og https://www.youtube.com/watch?v=ySDX02WD0og
Moru 5y ago
I bought a gps app several years ago after testing it out on my phone. It had everything I wanted and was fast and smooth on my phone. Next year I wanted to use it for a long trip but then it was updated, they had rewritten it from scratch. Most of the functions I liked were gone and the thing was slow like I have never seen. Battery drain was big, the phone got scorching hot. Now after 8 years it still does not have all the functions it had when I bought it and it's still too slow to be used even after changing to faster phone a couple of times. And still people are so fast to convert to latest frameworks and do complete rewrites. Most of the time recreating bugs they thought they got rid of many years ago. Or just make loads of new bugs. Or make it so slow on old phones that it can't be used any more.
- overflow897 5y ago
  Evernote is pretty much ruined for me because of this. From a lovely, snappy native app to an electron monstrosity that's slow and barely usable. Lucky for them their only competitor is Notion, another slow js app.
- cudgy 5y ago
  Probably they decided to ditch their native app for a cross-platform web based resource hog.
  - Moru 5y ago
    Yeah, think they said it was an electron app now.
HWR_14 5y ago
You left out the most important part. Sexy is a moving target. By the time your multiple years of incremental work moving it over are done, the new technology will be old and unsexy. Heck, in some cases the very fact that you(uncool company) use it will cause it to be unsexy.
akagusu 5y ago
One interesting outcome of Twitter's claim was other startups moving away from Rails towards other stacks.

ggm 5y ago

In my not infrequent rants inside the company I work for, I stand on one side of a major philosophical disagreement about old languages. The proponents of "keep coding in this old language" are also the people who want to retain the 5-10 year old OS, DB, and assumptions about external threat models and technical debt. Suffice to say nobody I ask outside of this company wants to adopt this model: Retained old platforms plagues the banking and finance sector. A 1950s OS called LEO was emulated by a 1960s OS called GEORGE which in turn is emulated by 1970s and 1980s ICL/Fujitsu mainframes, all because the core finance app is in COBOL and two greybeards per bank are on $mil to keep it working...

scarygliders 5y ago
Banking... - Does that COBOL code do the thing(s) it's supposed to in a reliable and 100% predictable way? My guess is : Yes it does. So let's go down your path. You rewrite that COBOL program using your hot new recent language of choice. How many new bugs will be introduced? What other risks are there in this new language; CVEs? RCEs? Simple coding bugs which could cost that bank millions/billions/trillions - or just as bad, the bank's customers their savings/livelihoods? Which New Hotness language would you rewrite that crusty old COBOL application in? Rust? [0] Golang? [1] Something else? There are times when it's better to leave the New Hotness to some new application rather than trying to replace a known reliable/predictable system with New Hotness. Especially for banking. [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=golang https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=golang
- Moto7451 5y ago
  Every couple of years someone at work rewrites the email sending code in a new sexy language and reimplements the same 7 bit encoding bugs as well as other subtle email encoding issues. This happens even with ample documentation and code comments about why specific conditionals are set.
  - SenHeng 5y ago

WrtCdEvrydy 5y ago

I've been through this multiple times. By the time you have something that is as good as what you had before the rewrite in the new programming language, the cost reductions will not be worth it.