[jacques_chester]

I felt that the "hitting the guardrails" example was a bit mixed. Adjusting in reaction to a sensed environment is pretty much what control means. On further reflection, it signals that the rest of the article intends to set up a false dichotomy that relies on a definition to serve in place of a proof.

The central puzzle is the idea that one can have "intellectual control" -- what seems to be a kind of metaphysical confidence in the software -- without, you know, using it. Yes, there is a nod to formal methods. Sure, there are types. But the author appears to simply handwave away the step at which the Mighty Controller Of Intellect runs the software. At which point he or she is -- gasp! -- testing the software. Comparing the theory to the reality and updating each as seems prudent.

It seems as though the author instinctively feels that there must a hatchway out of the universe into the Platonic realm. But then faces the old problems of dualism: how, pray tell, does this mysterious crystalline form actually interact with boring statistical matter?

Edit: I updated this comment several times, so you'll see scar tissue where I stitched it.

[gfairbanks]

Hi Jacques, author here. I'm a big fan of testing so I'm disappointed if the article gave the opposite impression. You won't find me saying "of course I didn't test it; I proved it correct." I was trying to use the guardrails metaphor as an intuitive segue to a topic that's boring but important, something that's more approachable than just proofs vs tests.

I think Dijkstra wouldn't be satisfied with anything other than proofs. The article is meant to look at the ways we write programs that fall short of his standard (ie almost everything) and ask if there are gradations there. I find pretty big differences in code that's written to meet the lowest bar of "just pass the tests" vs code that's written with the intent of keeping its state space small, methods tidy, and overall complexity limited. I don't know of great language to convey that distinction so I'm borrowing the term "intellectual control".

The article is also available as HTML: https://ieeexplore.ieee.org/document/8611447

[jacques_chester]

I generally take the view that authors have the best insight on their intention, so I apologise for my misreading.

> I find pretty big differences in code that's written to meet the lowest bar of "just pass the tests" vs code that's written with the intent of keeping its state space small, methods tidy, and overall complexity limited.

I think maybe this is where the misunderstanding arises. I'm used to TDD which amongst other things places pressure on the codebase to remain testable. The things that make code testable also, roughly speaking, make it reusable as well (test code is just code, after all). But more important than any one practice or tool is people just giving a damn about doing the work well.

This might be an example of Goodhart's Law: if someone throws a test suite over a wall[^] and says "here, make these pass or you're outta here", then the motivation to cut corners is going to be intense. Attempts to create control loops over humans that rely on mechanical behaviour by humans tend to fail. Steering wheels don't have families and mortgages, wing flaps aren't thinking about their next promotion.

The best discussion I've read about the problems of using measurements and targets to control (in the engineering sense) skilled workers is Measuring and Managing Performance in Organizations by Robert D. Austin. He elegantly demonstrates that the less directly-observable the work, the more destructive attempts to externally control it are. Which fits with my updated understanding of what you intended to say.

[^] this doesn't have to be a current wall, either. It can be the wall of elapsed time: the flaky tests of yesteryear can be a very particular kind of curse.