> I cannot agree that programming language choice is a primary driver in a product's success or failure....

This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles.

I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that is because I live in the world of "enterprise" code where for example:

* I'm called to do a rewrite

* I see the screenshot of the main app

* I guess correctly was made with vb (first big alarm) (how I know: I never see in my circle anybody that do vb, php, c, c++ anything resembling a sane UI. BTW just the use of colors was enough to guess)

* I worry, but confirm, that use Access as the main db

* I discover that part of the data was ALSO in a excel file, that is used with the equivalent of "joins", and was not surprised to see things like this

Even without knowing more about the people that do it, that is far enough signals to guess much.

BTW, there are very good predictors, if Use: MySql, MonGo, Php, Js (almost whatever you wanna add here in terms of frameworks), VB, Perl, Android (aka: Java android and android itself without using iOS alongside), is likely terrible. Then Java or C# taking turns how much worse, but not as bad as the ones before. I sweat if somebody say it use C or C++. Probably enough to straight refuse to take the project.

Any use of not-obscure tech in this sector and is a good predictor to be more or less not-that-bad.

BTW: Also complex infra and related boilerplate is now probably a stronger predictor after some langs like python, go, typescript and more modern java/kotlin/c# has spread (and also more pg and much less nosql, but too much "cloud")

I'm reminded of Paul Graham writing

> the CTO couldn't be a first rate hacker, because to become an eminent [Windows] NT developer he would have had to use NT voluntarily, multiple times, and I couldn't imagine a great hacker doing that

https://www.paulgraham.com/gh.html

If you are called in to rewrite the project, I would say this signals a successful project: it was built in whatever tech stack a midling engineering team had competency in, it originally worked well but started struggling with more scale/needs/updates, and it is still worth enough to invest in rewriting it.

Yes, you may not enjoy turning a legacy system that works into a nicely architected system, but the ones that get to that phase are clear successes IMO.

Contrast this with systems which had nice, clean, maintainable architecture from day one but bit the dust two years later.

The original article is a silly shill, as engineering managers have looked at economic cost of choosing a language and other technology since... forever.

And some of that "invisible" discussion happens visibly too (I've done that a number of times: "how do we keep our engineers motivated who want to explore a new hyped tech stack vs the cost of them being slower or leaving the company").

I think you’re confusing cause and effect. The cause here is bad engineering. The effect is bad architecture and unmaintainable software.