My understanding of the Asiana crash was that the autopilot would have landed the plane fine, and that it was the humans turning it off that caused the problem.
Your point is still valid, but perhaps we approach a time when over-reliance is better than all but the best human pilots (Sully, perhaps).
What's interesting is the number of people posting here who found the questions ambiguous. One assumes that your average HN poster may be a little overly detail oriented (and privileged), but even so... what this seems to be testing as much as algebra skill is correctly parsing the question (assuming there is a single 'correct' way to do that). Shouldn't that skill be part of the reading comprehension testing? Ask any customer facing developer and they will tell you there is no single interpretation for most customer requirements.
My other concern was the answer to #1, namely, "4m + 5b" vs "5m + 4b". I feel like if you know it is in that form (sum rather than product) the two answer choices are just intended to trip people up who are moving through the test at speed.
Felt this was glossed over. It's all well and good to not be too harsh for the reasons they mentioned, but ultimately the point is to 'peer review' the science.
In fact I would say an important "mistake reviewers make" is ... not actually doing much work. I've seen some appalling 2-3 line comments like "seems fine", even from senior academics. That's not even to talk about problems with misunderstood p-values, not reading the algorithm closely, not walking through the proof manually, and so on.
This is interesting work. I'm curious how confident we can be that the TLA+ proof from Diego Ongaro was correctly represented in Verdi/Coq. This still seems like a manual, hard-to-verify process.
I like the tool. As for the extensions, I would suggest that in my experience SonarQube has the same ability for extension, and does most of its work in the open. So it might be worth considering turning your project into a plugin (or plugins) for SonarQube?
(author here)
We cross-tabbed system age vs perception of amount of TD. There was a moderate association between older systems (> 6 yrs) and more perceived debt.
I did not explicitly look at size as this was not one of the original research questions, but a good point. I suspect older systems will tend to be larger (in the domains we studied, anyway). And your point about arch choices being great "early on" can, I think, be captured in the "system age" variable. I guess I'm trying to think of a system that might be young and yet quite large in LOC.. would be an interesting outlier to look at.
Perhaps lazy, perhaps working 20 other cases, or just lacking technical sophistication. If it was me it would be much simpler to issue a subpoena then engage in some sort of sting operation where things could go wrong.
I think the key one here is "XHTML:HTML". Like HTML markdown offloads the responsibility onto the parser writer to figure out what was intended. So while I sympathize with Github and Stack Overflow, as a user it should just work. And usually does.
As I understood it, the point is not that human intelligence never works. Rather, it works unpredictably. One can argue that the Sorge episode is random chance: the chance of someone acting on correct information is equal to the chance of someone acting on the wrong information. Sorge's own story about the German invasion proves this out.
There are a few courses doing that. I offered one that had student teams present a chapter each; Ric Holt at Waterloo was also doing something similar with reports. You can read a bit more about it on my blog [1].
It initially didn't fix the resolution issue for me. The trick, according to MacRumours, is to touch the .app files. A Mac caching issue. E.g. "touch /Applications/Microsoft Office/Microsoft\ Word.app"