You called my number absurd even for SV. As you now see, it is reasonably accurate. That you thought it was absurd instead of reasonable shows you are missing key information in the cost-benefit calculation. It might be prudent to re-evaluate your preconceptions in light of that.

As for your other numbers you again point at salary. What matters to a company is fully burdened cost per developer-time. European countries have higher benefits and lower hour/day expectations per year which skew the ratio relative to the US. I am not super familiar with the standard rule-of-thumb multiplier in western Europe, but the difference in fully burdened cost is less skewed than it seems based on salary, probably only 2-3x cheaper at most.

As for China, you used the yen conversion rate, not the RMB/yuan conversion rate. 269,904 RMB is ~37 K$, not 1800 $.

Paying fractions of employee cost in tooling is only viewed as absurd in software. In literally every other industry spending tens to hundreds of thousands of dollars per engineer to make them productive is just viewed as good business sense.

Even outside of engineering almost every industry spends more as a percentage on employee tooling. Do you see how many tools your average carpenter, plumber, or electrician has? Landscapers, architects? Even secretaries get those neat expensive printers and management software.

The point I am making is that tens of thousands of dollars for tooling is not “insane”. It deserves a calm cost-benefit analysis which can quite easily come on the side of worth it. Obviously, it can also come on the side of, this is a piece of trash, but that should be out of analysis, not a knee-jerk “too expensive”.

I don't think your number is reasonably accurate. 12 days wasn't close to accurate except in the insane world of SV.

Just because something is "normal" in other parts of the industry doesn't make it correct. The only reason these industries pay that sum is because they have literally no choice. They are essentially held hostage by the companies that build the tooling.

Precisely because many software engineers have seen the insanity of those fields they view paying for tools as a huge risk. No one wants to go back to the time when you had to pay monthly to get a shitty compiler with barely existing support.

You seem to be extremely fixated on the exact number of 12. Any number short of 100 junior dev-days does not even warrant considering the word “crazy”. Multiply all the numbers by 8 for all I care, it does not affect the conclusion that you should be doing a cost-benefit analysis, not dismissing it out of hand. Tens of thousands of dollars is a worthwhile price to pay for quality tooling that offers modest improvements; not big, modest.

You need to get to around 500 dev-days per developer in tooling before you get into “the probability this makes sense is almost certainly zero, so just dismiss it out of hand as too expensive”. That is hundreds of thousands of dollars per developer before we actually get into economically unjustifiable land.

And again, you are not distinguishing between what is economically sound versus the cost-benefit analysis of specific products. It is economically sound to spend a additional 10 K$ per developer you have in the Netherlands for tooling that offers a 30% productivity improvement (actually, it is economically sound to pay a great deal more, but that requires a more exhaustive analysis).

In other words, if you find a tool that you believe (including all factors like legal, licensing, whatever) actually provides a 30% overall productivity improvement then you would be economically foolish not to purchase that product for 10 K$/yr per developer. Note that I already incorporated all objections into your belief of a overall 30% improvement, we are starting from the assumption that including all caveats you are nearly certain you will get a 30% improvement.

But again, this depends on actual products meeting those parameters. Maybe all of the paid products suck. Fine, then they all fail the cost-benefit analysis. But that is because the benefit was not there for the cost, not because the cost is outrageous. Those are different fundamentally different concepts and should be treated differently.

> Paying fractions of employee cost in tooling is only viewed as absurd in software. In literally every other industry spending tens to hundreds of thousands of dollars per engineer to make them productive is just viewed as good business sense.

I suspect that part of the problem is that it's difficult to measure developer productivity, while it's a lot easier to measure headcount.

> In China a junior dev makes about ¥269,904 a year, or $1.806,89. Is this tool worth 5+ man years of a junior dev?

Try doing the currency conversion from Yuan to Dollars and not from Yen to Dollars.

> The tool would have to be pretty damn good. And also not introduce business risk or at the very least a minimal business risk.

That is actually quite possible. Ada is in a really good place as far as that goes: imagine the cost of writing an IDE (to include compiler) for, say, Ada, PL/SQL, and VHDL -- given the common lineage, you could make a custom internal representations (IR), where each language has a 'Subtype' constraint for its particularity (e.g. `Subtype Ada_IR is General_IR with Dynamic_Predicate => Is_Common(Ada_IR) or Is_Ada(Ada_IR);`, and so on for PL/SQL and VHDL), make these IRs with SPARK proving, as you implement PL/SQL and its query-engine also implement SPARK's proof-tools and SMT-interfaces, proving it as you go, next implement and prove code-gen/HW-synth.

Now, put the IDE source through the IDE, and BAM! Now you have a proved IDE+compiler for Ada, PL/SQL, and VHDL giving you a very solid platform. (Also, as you would have a DB-engine onboard, you could populate the IDE with templates and run a query like: SELECT Name, Code FROM Entities WHERE Purpose LIKE “%SCSI%”;... or SELECT Name, Purpose FROM Algorithms WHERE Purpose LIKE “%SORT%” AND Ω <= log_2;.)

Also, being Ada-based, you could use Ada's Distributed Systems Annex to distribute portions of the IDE, and/or implement CI/CD as per https://users.ece.utexas.edu/~perry/work/papers/icsm87.pdf