> 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
Meanwhile Valve has to make use of Proton, because the CTOs of game studios prefer to ignore GNU/Linux existence as gaming platform.
Maybe first rate hackers don't play games. /s
Maybe first rate hackers aren't a large market for games. Maybe long-term binary compatibility has created difficulties for game studios. Maybe Windows isn't as unusable as it was in 1995.
It was usable enough in 1995 for the same game studios.
Games in 1995 were targeting DOS and Windows 95, not Windows NT. They were doing so because that's what was on the majority of consumer PCs, and their objective was to sell games. People selecting a server-side OS and dev tools didn't have to worry about what ran on end user machines.
If you look hard enough, you'll find exceptions of course. I think Ebay was built on Windows servers, but in the late 1990s, building your web startup on Windows was a sign that your technical leadership had bad taste and a competitor would run circles around you.
Still it was Windows, and not first rate hackers operating systems.
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").
Yes.
And because time to first release is often the difference between prosper and fail
It is not enough to be the best. You need to be the first
I think you’re confusing cause and effect. The cause here is bad engineering. The effect is bad architecture and unmaintainable software.