I think the hardest conversation circles around language choice. One problem with choosing innovative languages is that you can end up on a dead end. Zipcar, for example, used Tcl. While I am a fan of Tcl, it became obvious around 2012ish (IIRC) that this was not the future. There was a first attempt at a migration using rails, but that ended up being ditched for a JVM stack. (I don't know if most of it is still in groovy, but there were also pieces in ruby, kotlin, and java.) We also had a large number of performance and billing problems we needed to solve, and as we were guaranteeing compatibility and interoperability (a big bang switchover was too risky for many reasons), we had a lot of performance and usability issues for years.
It cost far more than management expected in the outset for many reasons, but at the same time, staying on Tcl was unsustainable for developer recruitment and retention purposes. It's something that biases me toward blub languages now as a manager unless you have a very good reason to innovate there.
> … staying on Tcl was unsustainable for developer recruitment and retention purposes…
I agree that this is a real phenomenon, and I find fascinating because it illustrates the role of fashion in software development. TCL may have been quirky compared to other languages, but actual working software was successfully developed in it by more-or-less typical developers. Yet it failed anyway because it wasn’t “cool”.
Not being trendy meant that fewer brains were thinking about it, evolving it by improving tooling and writing libraries, producing training materials and evangelizing it. Ultimately it just stagnates.
I don't even know if it's "fashion" as much as an industry that only knew that java 1.2 wasn't going to be the path forward if you wanted to develop with speed. There was no guarantee python or php were going to be the winners.
I think it does speak to the amount of labor that goes into making a language viable as an option, though. Java had paid labor. Tcl didn't have enough unpaid labor to succeed while python did.
> 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.
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.
> 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.
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.
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.
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.
I think the hardest conversation circles around language choice. One problem with choosing innovative languages is that you can end up on a dead end. Zipcar, for example, used Tcl. While I am a fan of Tcl, it became obvious around 2012ish (IIRC) that this was not the future. There was a first attempt at a migration using rails, but that ended up being ditched for a JVM stack. (I don't know if most of it is still in groovy, but there were also pieces in ruby, kotlin, and java.) We also had a large number of performance and billing problems we needed to solve, and as we were guaranteeing compatibility and interoperability (a big bang switchover was too risky for many reasons), we had a lot of performance and usability issues for years.
It cost far more than management expected in the outset for many reasons, but at the same time, staying on Tcl was unsustainable for developer recruitment and retention purposes. It's something that biases me toward blub languages now as a manager unless you have a very good reason to innovate there.