Yeah, I've come to similar conclusions about Agile. It can be a great way for an already well-disciplined organization to think about the work they're doing. But many, many undisciplined organizations thought that Agile would be a catalyst for them to become disciplined. But the nitty gritty of "doing Agile" required EVEN MORE discipline than what all these organizations were already capable of exercising, so it just highlights all the frustrations everyone already has.
That does seem to be the downside of Agile. It's a collection of maybe a dozen different techniques and practices. But if one of those practices falters, whether it's the TDD, or the business side still wants a certain deadline, or you don't bother to demo at the end of a sprint, then the whole house of cards falls like dominoes..... checkmate!
One big factor that I don't THINK the article touches on is how we are using 'space' metaphors (speed and distance) for our work that's very 'time' based (working productivity and duration). And I think when we estimate, we try to estimate distance/duration but we forget that we're really trying to estimate our speed/productivity.
Where that gets painful is, say you estimate you can get something done in two days. In reality, you're twice as fast (there's that speed metaphor), so you actually get it done in one day. Yay, you saved a day! Now assume you're twice as slow as your two day estimate. Boo, you spent TWO days longer. So in terms of duration, getting it incorrect in the painful direction seems like a bigger mistake.
I don't think this is the same phenomenon as the author's mean vs. median dilemma. I'll bet both the mean vs. median and the productivity vs. duration dilemmas are real factors though.
A counter-argument is that even someone like you who doesn't use facebook, amazon, and google is still irrevocably affected by their power and behaviors. You seem to think you've escaped them, but you surely have a Shadow Profile in facebook, you browse websites that show you AdSense ads (google), and oh yeah, your civic institutions are manipulable via popular opinion on facebook. Hmmm, you do have a strong point about Comcast and Verizon, but I think there's a false choice in there.
Two months ago, Apple announced an ECG sensor for your wrist. A year before that, they announced face detection for the purposes of identity with enough accuracy that it can be used for financial transactions. Also, AirPods are incredible. I'm not saying Apple has a monopoly on invention, but to say they 'used to be an inventor'? That's weird.
Yeah... Just yesterday I was driving at night, through road construction, with a torrential downpour, and nowhere to pull off, and it was freaking scary. And I remember just thinking, "This kind of thing happens to me maybe a few times a year and there's no way in 30 years that we're going to trust autonomy with this"
As I read through the meltdown paper, it looks really difficult to have the security we want and the performance we want at the same time. It's pretty crazy, but here's my limited understanding:
There's a huge shared buffer between two threads. 256 * 4K. One thread reads a byte of kernel memory, literally any byte it wants, and it then reads one of those 4K pages from that buffer in order to cache that one memory page that corresponds to the byte it just read. Then at some point the CPU determines that the thread shouldn't be permitted to access the kernel memory location, and rolls back all of that speculative execution, but the cached memory page isn't affected by the rollback.
The other thread iterates through those 256 pages, timing how long it takes to read from each page, and the one page that Thread A accessed will have a different (shorter?) timing because it's cached already. It now understands one byte of kernel memory that it shouldn't. That's just one byte but the whole process is so fast that it's easy to just go nuts on the whole kernel address space.
So what would the fixes be? Disable speculative execution? Only do it if the target memory location is within userspace, or within the same space as the executing address? Plug all of the sideband information leak mechanisms? I dunno.
So is speculative execution just inherently flawed like this, or can we expect chips in 2 years that let operating systems go back to the old TLB behavior?
That does seem to be the downside of Agile. It's a collection of maybe a dozen different techniques and practices. But if one of those practices falters, whether it's the TDD, or the business side still wants a certain deadline, or you don't bother to demo at the end of a sprint, then the whole house of cards falls like dominoes..... checkmate!