Domains in which this is true, specifically domains for which "negative training" gets people killed, are probably the best bet. Military, LEO, disaster preparedness training spring to mind. However, the cost of the real world training exercises replaced has to be more than the cost of the VR, or the training exercise has to be impossible or too dangerous to pull off in the real world.

Source: was at BBN while DARPA pushed the Internet and created SIMNET. Did work for DARPA at own company later. Never met a wooly-haired, wild-eyed fellow nerd or VC with half the imagination of buzz-cut DARPA people.

An in-all-ways superior, analytical model you really ought to know is outlined here:

https://witseie.github.io/software-dev-3/docs/lehmans-laws.p...

RIP, Professor Lehman

While I do not believe I am at liberty to provide details (even lo so many years later), I was witness to the first use of (arguably) VR to prototype and introduce a new weapons platform into a combined arms battlefield simulation. The short version is that on Monday morning, despite all the deep thinking done by smart people about how this would all work out, none of us came close to predicting what turned out to be the net effects of the new system as seen by Friday. I was there in my capacity as a nerd simply to keep the blinking lights blinking (vs the capacity of a combat domain expert), but watching the whole thing unfold was a mind-blowing demonstration of the "Law of Unanticipated Consequences."

None of us are as smart as we think we are. We are no smarter than our adversaries. The world is more complex than either of us can know.

Under active development. Turtles all the way down. Runs on Linux, Raspbian, etc. Runs under (at least) SBCL & CCL.

Don't forget to click the "See all 9 images" link for what I hope you will find to be a treat. (In the interest of full disclosure, I have no financial interest in the book - however, I did buy a copy myself.)

Built with reasonably recent McCLIM and SBCL. At one point, had it running under CCL on one of my Raspberry Pi boxes (the 3, I think). Would have made a cool pocket, ersatz LispM.

Source code:

https://bitbucket.org/symbolicsimulation/com.symsim.oss.lisp...

Yeah, I know it's a mess. With the exception of updating the calls to the inspector just now (in case anybody tried to build it), it's just as I last left it a few years ago - with the proverbial hood open, subsystems not really working, and parts lying all over the floor.

I believe Lehman formalizes the dichotomy you imply as bugs in the "model" (you say "specification"), and bugs in the model's implementation. I think the distinction is important in that the model/spec is an evolving/moving target, subject to evolutionary forces. And the number of bugs in the implementation of any given model's snapshot in time is an increasing function of SLOC, and that updating the model can produce more/latent bugs in previously un-buggy code. (Which I take to mean we need minimize lines of code for any given amount of functionality. Less to write, less lines containing bugs, less to modify, etc.)

Regarding (1): I agree that we perform vastly below our potential due to bugs, but also many other factors - though it might be hard to agree on the what those contributory factors are, and their relative contributions.

I of course realize that people are not perfect (along any axis at all), but I think the importance of this work is highlighting:

(1) software must evolve in order to continue being useful (is this the "cultural" part of your comment?), and

(2) that there are some unavoidable limitations of human capability to achieve that (is this the "people being shit" part of your comment?), particularly in dealing with complexity. And that complexity is an increasing function of lines-of-code count.

So, the obvious conclusion to draw (for me, anyways), is we should work to minimize SLOC by various means: DSLs, &/or expressive/powerful languages.

http://ai2-s2-pdfs.s3.amazonaws.com/5454/5a907a43c798c1193be...

His resulting model of software evolution explains many observations we engineers make about "feature creep," "technical debt," balance of effort between development and maintenance, etc.

I think his model also helps point the way to techniques we can use (e.g., DSLs in preference to OOP) to help improve how we build and maintain software.