5 ms·

> staying on Tcl was unsustainable for developer recruitment and retention purposes I'm not sure I get this. Any competent programmer can learn Tcl. So find on

> staying on Tcl was unsustainable for developer recruitment and retention purposes I'm not sure I get this. Any competent programmer can learn Tcl. So find one versed in scripting languages like Python or Ruby, and they can learn how Tcl works in a week and learn how the program is structured over a few weeks and start making small changes. I'm skeptical that this training overhead would really cost more than replacing the whole system if it really was working well.

cjpearson 4y ago
I doubt training was the issue. There are many languages that developers can work with, but would rather not. They might have a personal dislike of the language, be persuaded by industry fashions, or worry that they'll be harming their future career prospects.
- naasking 4y ago
  Sure, but there are also plenty of good ones that wouldn't think this way.
lelanthran 4y ago
> I'm not sure I get this. You're looking at it soley from the PoV of the company. > Any competent programmer can learn Tcl. So find one versed in scripting languages like Python or Ruby, and they can learn how Tcl works in a week and learn how the program is structured over a few weeks and start making small changes. Sure, but why would they want to? They'd be wasting time on a skill that adds exactly $0 to their market value. The longer they stay with you, spending time getting experienced with Tcl (and not with some other popular language), the less they are worth. > I'm skeptical that this training overhead would really cost more than replacing the whole system if it really was working well. For the company, no. For the developer, most developers tend to shy away from dead-end tech stacks. If you get someone close to retirement (10 years away), they'd be happy to use your dead-end tech stack, because to them their current market value gets more irrelevant with each passing day.
- naasking 4y ago
  > You're looking at it soley from the PoV of the company. No, I'm not. I personally am not at all concerned about "dead-end tech stacks" because the kind of companies that care that you have specific skills rather than overall engineering competence are not the ones I want to work for. I'm sure I'm not the only one.
  - aliswe 4y ago
    People in general don't want to work with dead languages - it is in fact a retention and recruitment problem.
    - naasking 4y ago
      I already agreed that "people in general" don't want that. I don't see how that refutes my argument that enough people don't think that way that it might have been cheaper to pay such a person.
ebiester 4y ago
People were leaving the company, and recruiters were having difficulty bringing great programmers in at the price that they were willing to pay. (I could argue it would have been cheaper to pay programmers a premium to work in the technology, given how much money it cost to rebuild the system and how much more in infrastructure costs the new microservices system cost relative to one production server and one (Oracle) database.) And as people left, the theory of the program was being lost, turning it into "legacy code." There were other problems as well - in particular, the initial data structures that were coupled to billing made it difficult to try other business models, and the industry was starting to innovate with point to point in other markets. Those were solvable in Tcl, though. The real problem was people.
- naasking 4y ago
  > recruiters were having difficulty bringing great programmers in at the price that they were willing to pay. Right, it's always something like that. Thanks for clearing that up.

cjpearson 4y ago

I doubt training was the issue. There are many languages that developers can work with, but would rather not. They might have a personal dislike of the language, be persuaded by industry fashions, or worry that they'll be harming their future career prospects.

naasking 4y ago
Sure, but there are also plenty of good ones that wouldn't think this way.

lelanthran 4y ago

> I'm not sure I get this. You're looking at it soley from the PoV of the company. > Any competent programmer can learn Tcl. So find one versed in scripting languages like Python or Ruby, and they can learn how Tcl works in a week and learn how the program is structured over a few weeks and start making small changes. Sure, but why would they want to? They'd be wasting time on a skill that adds exactly $0 to their market value. The longer they stay with you, spending time getting experienced with Tcl (and not with some other popular language), the less they are worth. > I'm skeptical that this training overhead would really cost more than replacing the whole system if it really was working well. For the company, no. For the developer, most developers tend to shy away from dead-end tech stacks. If you get someone close to retirement (10 years away), they'd be happy to use your dead-end tech stack, because to them their current market value gets more irrelevant with each passing day.

naasking 4y ago
> You're looking at it soley from the PoV of the company. No, I'm not. I personally am not at all concerned about "dead-end tech stacks" because the kind of companies that care that you have specific skills rather than overall engineering competence are not the ones I want to work for. I'm sure I'm not the only one.
- aliswe 4y ago
  People in general don't want to work with dead languages - it is in fact a retention and recruitment problem.
  - naasking 4y ago
    I already agreed that "people in general" don't want that. I don't see how that refutes my argument that enough people don't think that way that it might have been cheaper to pay such a person.

ebiester 4y ago

People were leaving the company, and recruiters were having difficulty bringing great programmers in at the price that they were willing to pay. (I could argue it would have been cheaper to pay programmers a premium to work in the technology, given how much money it cost to rebuild the system and how much more in infrastructure costs the new microservices system cost relative to one production server and one (Oracle) database.) And as people left, the theory of the program was being lost, turning it into "legacy code." There were other problems as well - in particular, the initial data structures that were coupled to billing made it difficult to try other business models, and the industry was starting to innovate with point to point in other markets. Those were solvable in Tcl, though. The real problem was people.

naasking 4y ago
> recruiters were having difficulty bringing great programmers in at the price that they were willing to pay. Right, it's always something like that. Thanks for clearing that up.