The primary point of a class action lawsuit isn't to "fight for the little guy," it is to punish companies that do wrong.
This is a useful purpose, but one that could be served just as well by fining the companies in question real money and directing it to some constructive destination determined by the court. There is no need to allow for the blatant enrichment of lawyers as the primary beneficiaries of such cases, which from an outsider's point of view seems to be the norm in US class actions.
The point of a class action lawsuit is that there are too many people who suffered minor damages to really be able to logistically handle that.
Perhaps it would be appropriate to require a failed defendant to compensate the individuals to a fair extent in any case. If the overheads of doing so are absurdly disproportionate, it will serve as a very practical punishment and a reminder of just how many people were harmed even in a small way.
Just because you don't have a subscription to the ACM Digital Library doesn't mean there isn't tons of research on the subject.
I live just down the road from one of the UK's national reference libraries. I've read tons of research on the subject.
You, I'm guessing, haven't. For example, I just looked up the second paper you cited there. It is not primary research, mentions the term "agile" only once in its entire content, and cites only two other related sources.
Then I looked up the first of those two sources. It appears to be based on self-reported, subjective preferences rather than objective, quantified data; it relates to general trends rather than specific practices; it has obvious selection bias problems; and even then it is equivocal in its conclusions.
I gave up at that point. Maybe something buried elsewhere in what you cited would be interesting, but you obviously just looked up a couple of random papers and posted them in the hope that you'd look like you knew what you were talking about.
If it doesn't and all these papers are flawed, then we have a bigger problem than whether or not Agile is successful.
Doing serious research into software engineering practices is very hard. It is extremely unusual to have the chance to compare two parallel implementations of equivalent or very similar non-trivial projects using two different methods. This is certainly a real problem.
Depending on where you are, you might be able to send them a Subject Access Request or your local equivalent, forcing them to provide you with all the personal data they hold about you, give or take a bit of wriggling on their part, for a token amount of money.
Agile methods only exist because they are more successful than older approaches.
As I said, I have yet to see convincing evidence that a lot of these trendy Agile processes are in fact measurably more successful than "older approaches".
If you lack published papers then: google!!!
I don't lack published papers. I've had an interest in this area for many years, and I've done much more than Googling. I've also looked through academic reference libraries, conference proceedings, subscription journals, and research from industrial R&D facilities, among other things.
And as I said, I have yet to find any significant amount of hard data collected using sound methodologies that supports these general claims about the superiority of various Agile methods. For example, a disturbing number of the "studies" are little more than watching a trivial coding exercise performed by a handful of undergraduate students, followed by completely unwarranted extrapolation to professional projects implemented by professional teams over extended timescales. TDD studies are a personal favourite of mine, where it seems to be almost universal to experiment with trivial CRUD applications that play to TDD's expected strengths, and where the control used for comparison is almost invariably having no testing at all rather than any of the numerous realistic alternatives.
To be clear, I am not arguing that none of the practices used by Agile is a good idea, nor that there is no evidence of any kind in favour of some of those practices. There is evidence that using automated unit tests reduces bug counts compared to not using them, for example. But if the kinds of unqualified blanket claims that Agile evangelists frequently make on forums like this one were really as clear-cut as they make out, the evidence of the superiority of methods like Scrum and XP ought to be overwhelming after this long, and it simply isn't.
Why do you think a company like EnBW or BASF has switched to agile methods and is not going back to the old way?
I don't know, but since we're talking about software project management in large organisations, there are plenty of plausible explanations that have little, if anything, to do with Agile consistently achieving objectively better results for those organisations.
I'd love to see a citation for that study. I've been waiting a decade for someone to show me actual data that supports a claim that various Agile practices cause a measurable improvement in some useful way, and so far I've yet to find a paper where the methodology and/or conclusions couldn't be debunked literally in a few seconds.
Stop moving the goalposts. We were talking specifically about the UK's closest equivalent to US Miranda rights. The question was why the right to remain silent, even when being formally questioned with legal representation present, should be protected, and how allowing someone under those conditions to change their story in court later and suddenly remember things convenient to their defence is actually in the interests of justice.
You still haven't given anything resembling an actual argument in support of that position. All you're posting is fear-mongering about some hypothetical bogeymen, and a few allegations that are disproved every day by the way our system actually works, for real, in practice, here in the UK. I think you don't have any logical or evidence-based argument to make, and you're just defending a legal right that the US singles out for protection because of dogma.
If you have anything with any real substance, feel free to post it and maybe I'll reply again, but otherwise this thread doesn't seem to be going anywhere.
duh, this is the purpose of miranda rights, to make sure that this happens! without the rights do you think police would wait for a defense lawyer to arrive?
Yes, I think that's exactly what happens here in the UK, which is where we're talking about in this thread if you recall.
Most of the exploits are based on human greed, stupidity, carelessness and/or lack of knowledge.
Sure. Most users aren't technical experts and will fall for a carefully constructed illusion.
But anyone who is using a computer on-line in a non-trivial way can be a victim of an attack. Zero-day exploits get found, and every major browser has been compromised, and every major OS has been compromised, and no amount of security software and hardware can make you completely immune to threats. You can do a lot to reduce the risk, but there's no such thing as perfect security in today's on-line world. The only way to avoid these attacks is not to enable on-line banking at all, which of course just creates other attack vectors instead because you need to do your banking somehow.
Having one person dictate what is and isn't patentable opens a huge can of worms
I think you're reading too much into what I wrote that isn't really there.
I am not talking about specific cases, I am talking about general principles and what the scope of patent protection should be. I have no problem with saying that, for example, patents should not apply to any information-based "invention" such as software, business methods, or scientific data. I also think it would be wise not to grant patents for any physical invention whose novelty is primarily or entirely in the information it embodies; for example, you can't just add "on a computer" to an otherwise information-based invention to overcome the intended exclusion.
It doesn't need one person to dictate that these things aren't patentable on a case-by-case basis. Just define what constitutes a patentable invention in a way that isn't absurdly broad. Clearly you can't dictate in advance which specific inventions are patentable, because you'd have to invent everything before it was invented, so you're going to need some sort of generic statement of the scope of patent protection whatever you do (unless you abolish patents altogether, which is a different question).
it's the job of police and prosecutors to get convictions, and they use every tool at their disposal to do so.
Once again that's a rather US-centric approach. To give a contrasting example again from here in the UK, there are plenty of times that the CPS (our public prosecution service) decide not to go ahead with a prosecution because they decide that it's not in the public interest.
the defendant should be able to plan his own defense (defence as you say) and so should be able to stay silent until consulting with an attorney.
Right, so as long as the questioning is taking place under caution and legal counsel is present, what's the problem?
Do these measures address arguably the most fundamental problem: too many things are patentable in the US and patents are awarded too easily in the first place?
Please stop putting words under my fingertips. I never said anything about governments never being bad, or about not protecting important rights. I just asked how protecting the specific "rights" we're talking about is in the interests of justice in modern society. And I notice that you still haven't even attempted to answer that question, and nor has anyone else in this thread.
There are a lot of things that weren't protected by other means in those days that would probably bring down governments if you tried to overturn them today, as for example women and anyone who isn't white can affirm.
So once more, I repeat the same fundamental question: How is protecting these "rights" in the interests of justice today?
I understand the things you described fine, and I'm also aware of some of the history that brought us to the current position. I just question whether the assumptions that led to that position a very long time ago are still relevant today, and therefore whether protecting those "rights" is still in the interests of justice.
Also, conflating completely different things (right to remain silent vs. right to informed legal counsel, for example) is a straw man, and a cheap shot that someone you disagree with "probably should not be participating in this discussion" is not an argument.
there's a difference between what you said and what the GP said. you said, "if you say A to us now, you won't be able to say B later in court."
Not quite. I said you couldn't change your story later and expect anyone to believe you, which would include for example implausibly forgetting some obvious and relevant detail at the interview stage and then suddenly having a precise memory of exactly your version of events in court later.
Also note that the exact wording of the caution here is that it may harm your defence, not that it necessarily will. As far as I know (IANAL) you can still say something in court that you didn't before, but you can also be asked to explain the discrepancy and a jury is allowed to draw inferences if they don't buy your explanation.
GP said "if you don't say A now, then you won't be able to say it later in court."
If that were what the GP had said, they would have been wrong, for the same reason as above.
The difference, of course, is the right to remain silent
Which is a rather strange "right" not necessarily expected or protected under all legal systems. I've never really understood the legal or ethical argument for why someone should be allowed to decline to present or defend their side of the story but then effectively be given credit for it anyway. How does this make a just and fair outcome to a trial more likely?
That's all fair enough, but you appear to be talking about specific oddities where US law redefines common language in specific and counter-intuitive ways. That doesn't necessarily mean anyone else in the world does so, and I see nothing in the context of the original quote to suggest that it was referring to any US jurisdiction.
From an outsider's point of view, the US authorities and in particular US LEOs seem to have a much more adversarial relationship with the citizens they allegedly protect than most other places. For example, here in the UK, "policing by consent" is the traditional stance, and even today most citizens, politicians, and police officers (of all ranks) tend to react with some hostility to any suggestion of changing to a more US-style approach.
Something like that seems reasonable enough. And if the camera footage is stopped other than as the officer walks into somewhere you would legitimately expect camera footage to be stopped, fall back to whatever presumption of tainted evidence position you would otherwise take if the camera "fell off accidentally" etc.
Alternatively, any officer can turn their own recording equipment off but it will make a clearly audible noise while disabled so they can't forget to turn it back on again and anyone they approach will know that recording is disabled. Only their shift supervisor or other responsible senior officer can turn the device on at the start of the shift and fully off again at the end. And to prevent tampering, any officer whose equipment isn't making proper noises at both the start and end of a shift is in trouble if they didn't call it in and return to base for a replacement immediately.
In practice, it's closer to "You can't mess us around even when it's in a recorded interview under caution with your lawyer present, and then change your story in court later and expect anyone to believe you".
Because an instruction to draw a certain inference about one aspect of a case because of a legal technicality is not the same as directing the jury to reach a certain verdict on the case as a whole.
You wouldn't want a guilty perp to go free just because of a glitch in the recording system
You wouldn't want a guilty perp to go free just because evidence was obtained inappropriately either, but you must (and almost all courts will) reject such evidence if you want standards for how evidence is fairly obtained to mean anything. If the case at hand can't stand up without it, that's unfortunate but necessary on a "greater good" basis.
In the case of copcam that we're talking about, the obvious analogue would be to give the benefit of the doubt to the non-officer in any case where an officer was or should have been wearing a copcam but the police fail to produce the evidence in court for any reason. In particular, in any case where there was a dispute over what happened, the evidence is otherwise inconclusive, and copcam footage would reasonably have been expected to show the events unambiguously, the presumption is that a suspect walks but a cop gets disciplined, and the failure to provide the evidence in one case should itself be admissible as evidence in future cases involving the same cop.
Did you notice the "and assaults on officers" part of the statement?
It turns out that most police officers in most places are actually decent people just trying to do a job under sometimes difficult conditions. While there are too many bad apples in the police and any abuse of powers/equipment they are allowed that the rest of us aren't is to be condemned and punished, there are also bad applies among the general public and abuse of the police officers by anyone else is also to be condemned and punished.
Sorry, but you are completely missing my point. My comment wasn't really about tests, it was about the fact that these huge projects are practically all-or-nothing in their success.
For that kind of project, you can't know whether you will ultimately succeed just because you adopt some sort of incremental development strategy. You could spend years of development time and a small fortune in expenses making exemplary progress and getting 90% of your system working fine, but if the last 10% turns out to be impossible you still have nothing.
In short, your wonderful ideal where "everyone sees that it probably won't work" reliably and after just a few weeks simply does not exist for projects on this scale, and no amount of buzzwords can change that.
I have never, not once, seen a requirements document that accurately captures exactly what the system will do. [...] The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want.
Well, in this case, "what they really want" tends to be defined literally by Acts of Parliament and/or policies set by the highest legal authorities in the government. I know it's popular to mock politicians in Europe for having no idea what they're doing economically, and it seems there's some truth to that in light of recent events, but you don't implement software to automate a major component of your national tax and benefits system in incremental changes with one guy designated as the project owner who can change his mind every now and then as you go along. That guy is the Chancellor of the Exchequer, and he has a few other things to do apart from responding in timely fashion to Bob the Programmer's request for clarification of how to implement the national tax rules.
The unstated assumption in that theory is that there is a group of human beings who are unto demigods, capable of defining detailed specifications that cover all eventualities, see far into the future, and can be implement mechanistically by simple code grinders.
I think you're extrapolating considerably there. In reality, the "unstated assumption" is probably a clearly stated and legally actionable rule that when the specs or overall architecture is deficient, as obviously these things will be sometimes on any large project, then it's the responsibility of the guys further up the tree to fix those problems rather than the job of the bottom-tier code monkeys to deviate from their specs.
Don't get me wrong, if you've got a good team building your company's software then I'm all for shallow management hierarchies and empowering individuals. But we're talking about a national government running a massive project to automate a large chunk of its tax and benefit system, with who knows how many people and of what quality involved in building it, and with literally life-changing consequences for many, many people if it goes wrong even for a few weeks. The rules of the game are very different, and the management style has to allow for that.
You're citing a company whose motto is "Move fast and break things", a company that is indeed infamous for breaking its software all over the place and introducing changes its users don't want, as evidence that cowboy programming works at scale?
Facebook have been shrewd about their marketing, and they've developed probably the most effective lock-in/network effect strategy in software history, and they've also been lucky at a few times when it counted, and they're successful as a result. Please don't confuse any of that with technical merit, which really has very little to do with their success or failure at this point.
Slashdot Mirror
The primary point of a class action lawsuit isn't to "fight for the little guy," it is to punish companies that do wrong.
This is a useful purpose, but one that could be served just as well by fining the companies in question real money and directing it to some constructive destination determined by the court. There is no need to allow for the blatant enrichment of lawyers as the primary beneficiaries of such cases, which from an outsider's point of view seems to be the norm in US class actions.
The point of a class action lawsuit is that there are too many people who suffered minor damages to really be able to logistically handle that.
Perhaps it would be appropriate to require a failed defendant to compensate the individuals to a fair extent in any case. If the overheads of doing so are absurdly disproportionate, it will serve as a very practical punishment and a reminder of just how many people were harmed even in a small way.
Just because you don't have a subscription to the ACM Digital Library doesn't mean there isn't tons of research on the subject.
I live just down the road from one of the UK's national reference libraries. I've read tons of research on the subject.
You, I'm guessing, haven't. For example, I just looked up the second paper you cited there. It is not primary research, mentions the term "agile" only once in its entire content, and cites only two other related sources.
Then I looked up the first of those two sources. It appears to be based on self-reported, subjective preferences rather than objective, quantified data; it relates to general trends rather than specific practices; it has obvious selection bias problems; and even then it is equivocal in its conclusions.
I gave up at that point. Maybe something buried elsewhere in what you cited would be interesting, but you obviously just looked up a couple of random papers and posted them in the hope that you'd look like you knew what you were talking about.
If it doesn't and all these papers are flawed, then we have a bigger problem than whether or not Agile is successful.
Doing serious research into software engineering practices is very hard. It is extremely unusual to have the chance to compare two parallel implementations of equivalent or very similar non-trivial projects using two different methods. This is certainly a real problem.
Depending on where you are, you might be able to send them a Subject Access Request or your local equivalent, forcing them to provide you with all the personal data they hold about you, give or take a bit of wriggling on their part, for a token amount of money.
Agile methods only exist because they are more successful than older approaches.
As I said, I have yet to see convincing evidence that a lot of these trendy Agile processes are in fact measurably more successful than "older approaches".
If you lack published papers then: google!!!
I don't lack published papers. I've had an interest in this area for many years, and I've done much more than Googling. I've also looked through academic reference libraries, conference proceedings, subscription journals, and research from industrial R&D facilities, among other things.
And as I said, I have yet to find any significant amount of hard data collected using sound methodologies that supports these general claims about the superiority of various Agile methods. For example, a disturbing number of the "studies" are little more than watching a trivial coding exercise performed by a handful of undergraduate students, followed by completely unwarranted extrapolation to professional projects implemented by professional teams over extended timescales. TDD studies are a personal favourite of mine, where it seems to be almost universal to experiment with trivial CRUD applications that play to TDD's expected strengths, and where the control used for comparison is almost invariably having no testing at all rather than any of the numerous realistic alternatives.
To be clear, I am not arguing that none of the practices used by Agile is a good idea, nor that there is no evidence of any kind in favour of some of those practices. There is evidence that using automated unit tests reduces bug counts compared to not using them, for example. But if the kinds of unqualified blanket claims that Agile evangelists frequently make on forums like this one were really as clear-cut as they make out, the evidence of the superiority of methods like Scrum and XP ought to be overwhelming after this long, and it simply isn't.
Why do you think a company like EnBW or BASF has switched to agile methods and is not going back to the old way?
I don't know, but since we're talking about software project management in large organisations, there are plenty of plausible explanations that have little, if anything, to do with Agile consistently achieving objectively better results for those organisations.
I'd love to see a citation for that study. I've been waiting a decade for someone to show me actual data that supports a claim that various Agile practices cause a measurable improvement in some useful way, and so far I've yet to find a paper where the methodology and/or conclusions couldn't be debunked literally in a few seconds.
Stop moving the goalposts. We were talking specifically about the UK's closest equivalent to US Miranda rights. The question was why the right to remain silent, even when being formally questioned with legal representation present, should be protected, and how allowing someone under those conditions to change their story in court later and suddenly remember things convenient to their defence is actually in the interests of justice.
You still haven't given anything resembling an actual argument in support of that position. All you're posting is fear-mongering about some hypothetical bogeymen, and a few allegations that are disproved every day by the way our system actually works, for real, in practice, here in the UK. I think you don't have any logical or evidence-based argument to make, and you're just defending a legal right that the US singles out for protection because of dogma.
If you have anything with any real substance, feel free to post it and maybe I'll reply again, but otherwise this thread doesn't seem to be going anywhere.
duh, this is the purpose of miranda rights, to make sure that this happens! without the rights do you think police would wait for a defense lawyer to arrive?
Yes, I think that's exactly what happens here in the UK, which is where we're talking about in this thread if you recall.
Most of the exploits are based on human greed, stupidity, carelessness and/or lack of knowledge.
Sure. Most users aren't technical experts and will fall for a carefully constructed illusion.
But anyone who is using a computer on-line in a non-trivial way can be a victim of an attack. Zero-day exploits get found, and every major browser has been compromised, and every major OS has been compromised, and no amount of security software and hardware can make you completely immune to threats. You can do a lot to reduce the risk, but there's no such thing as perfect security in today's on-line world. The only way to avoid these attacks is not to enable on-line banking at all, which of course just creates other attack vectors instead because you need to do your banking somehow.
Having one person dictate what is and isn't patentable opens a huge can of worms
I think you're reading too much into what I wrote that isn't really there.
I am not talking about specific cases, I am talking about general principles and what the scope of patent protection should be. I have no problem with saying that, for example, patents should not apply to any information-based "invention" such as software, business methods, or scientific data. I also think it would be wise not to grant patents for any physical invention whose novelty is primarily or entirely in the information it embodies; for example, you can't just add "on a computer" to an otherwise information-based invention to overcome the intended exclusion.
It doesn't need one person to dictate that these things aren't patentable on a case-by-case basis. Just define what constitutes a patentable invention in a way that isn't absurdly broad. Clearly you can't dictate in advance which specific inventions are patentable, because you'd have to invent everything before it was invented, so you're going to need some sort of generic statement of the scope of patent protection whatever you do (unless you abolish patents altogether, which is a different question).
it's the job of police and prosecutors to get convictions, and they use every tool at their disposal to do so.
Once again that's a rather US-centric approach. To give a contrasting example again from here in the UK, there are plenty of times that the CPS (our public prosecution service) decide not to go ahead with a prosecution because they decide that it's not in the public interest.
the defendant should be able to plan his own defense (defence as you say) and so should be able to stay silent until consulting with an attorney.
Right, so as long as the questioning is taking place under caution and legal counsel is present, what's the problem?
Do these measures address arguably the most fundamental problem: too many things are patentable in the US and patents are awarded too easily in the first place?
Please stop putting words under my fingertips. I never said anything about governments never being bad, or about not protecting important rights. I just asked how protecting the specific "rights" we're talking about is in the interests of justice in modern society. And I notice that you still haven't even attempted to answer that question, and nor has anyone else in this thread.
And how many centuries ago was that?
There are a lot of things that weren't protected by other means in those days that would probably bring down governments if you tried to overturn them today, as for example women and anyone who isn't white can affirm.
So once more, I repeat the same fundamental question: How is protecting these "rights" in the interests of justice today?
I understand the things you described fine, and I'm also aware of some of the history that brought us to the current position. I just question whether the assumptions that led to that position a very long time ago are still relevant today, and therefore whether protecting those "rights" is still in the interests of justice.
Also, conflating completely different things (right to remain silent vs. right to informed legal counsel, for example) is a straw man, and a cheap shot that someone you disagree with "probably should not be participating in this discussion" is not an argument.
there's a difference between what you said and what the GP said. you said, "if you say A to us now, you won't be able to say B later in court."
Not quite. I said you couldn't change your story later and expect anyone to believe you, which would include for example implausibly forgetting some obvious and relevant detail at the interview stage and then suddenly having a precise memory of exactly your version of events in court later.
Also note that the exact wording of the caution here is that it may harm your defence, not that it necessarily will. As far as I know (IANAL) you can still say something in court that you didn't before, but you can also be asked to explain the discrepancy and a jury is allowed to draw inferences if they don't buy your explanation.
GP said "if you don't say A now, then you won't be able to say it later in court."
If that were what the GP had said, they would have been wrong, for the same reason as above.
The difference, of course, is the right to remain silent
Which is a rather strange "right" not necessarily expected or protected under all legal systems. I've never really understood the legal or ethical argument for why someone should be allowed to decline to present or defend their side of the story but then effectively be given credit for it anyway. How does this make a just and fair outcome to a trial more likely?
That's all fair enough, but you appear to be talking about specific oddities where US law redefines common language in specific and counter-intuitive ways. That doesn't necessarily mean anyone else in the world does so, and I see nothing in the context of the original quote to suggest that it was referring to any US jurisdiction.
From an outsider's point of view, the US authorities and in particular US LEOs seem to have a much more adversarial relationship with the citizens they allegedly protect than most other places. For example, here in the UK, "policing by consent" is the traditional stance, and even today most citizens, politicians, and police officers (of all ranks) tend to react with some hostility to any suggestion of changing to a more US-style approach.
Something like that seems reasonable enough. And if the camera footage is stopped other than as the officer walks into somewhere you would legitimately expect camera footage to be stopped, fall back to whatever presumption of tainted evidence position you would otherwise take if the camera "fell off accidentally" etc.
Alternatively, any officer can turn their own recording equipment off but it will make a clearly audible noise while disabled so they can't forget to turn it back on again and anyone they approach will know that recording is disabled. Only their shift supervisor or other responsible senior officer can turn the device on at the start of the shift and fully off again at the end. And to prevent tampering, any officer whose equipment isn't making proper noises at both the start and end of a shift is in trouble if they didn't call it in and return to base for a replacement immediately.
In practice, it's closer to "You can't mess us around even when it's in a recorded interview under caution with your lawyer present, and then change your story in court later and expect anyone to believe you".
Because an instruction to draw a certain inference about one aspect of a case because of a legal technicality is not the same as directing the jury to reach a certain verdict on the case as a whole.
You wouldn't want a guilty perp to go free just because of a glitch in the recording system
You wouldn't want a guilty perp to go free just because evidence was obtained inappropriately either, but you must (and almost all courts will) reject such evidence if you want standards for how evidence is fairly obtained to mean anything. If the case at hand can't stand up without it, that's unfortunate but necessary on a "greater good" basis.
In the case of copcam that we're talking about, the obvious analogue would be to give the benefit of the doubt to the non-officer in any case where an officer was or should have been wearing a copcam but the police fail to produce the evidence in court for any reason. In particular, in any case where there was a dispute over what happened, the evidence is otherwise inconclusive, and copcam footage would reasonably have been expected to show the events unambiguously, the presumption is that a suspect walks but a cop gets disciplined, and the failure to provide the evidence in one case should itself be admissible as evidence in future cases involving the same cop.
Did you notice the "and assaults on officers" part of the statement?
It turns out that most police officers in most places are actually decent people just trying to do a job under sometimes difficult conditions. While there are too many bad apples in the police and any abuse of powers/equipment they are allowed that the rest of us aren't is to be condemned and punished, there are also bad applies among the general public and abuse of the police officers by anyone else is also to be condemned and punished.
Sorry, but you are completely missing my point. My comment wasn't really about tests, it was about the fact that these huge projects are practically all-or-nothing in their success.
For that kind of project, you can't know whether you will ultimately succeed just because you adopt some sort of incremental development strategy. You could spend years of development time and a small fortune in expenses making exemplary progress and getting 90% of your system working fine, but if the last 10% turns out to be impossible you still have nothing.
In short, your wonderful ideal where "everyone sees that it probably won't work" reliably and after just a few weeks simply does not exist for projects on this scale, and no amount of buzzwords can change that.
I have never, not once, seen a requirements document that accurately captures exactly what the system will do. [...] The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want.
Well, in this case, "what they really want" tends to be defined literally by Acts of Parliament and/or policies set by the highest legal authorities in the government. I know it's popular to mock politicians in Europe for having no idea what they're doing economically, and it seems there's some truth to that in light of recent events, but you don't implement software to automate a major component of your national tax and benefits system in incremental changes with one guy designated as the project owner who can change his mind every now and then as you go along. That guy is the Chancellor of the Exchequer, and he has a few other things to do apart from responding in timely fashion to Bob the Programmer's request for clarification of how to implement the national tax rules.
The unstated assumption in that theory is that there is a group of human beings who are unto demigods, capable of defining detailed specifications that cover all eventualities, see far into the future, and can be implement mechanistically by simple code grinders.
I think you're extrapolating considerably there. In reality, the "unstated assumption" is probably a clearly stated and legally actionable rule that when the specs or overall architecture is deficient, as obviously these things will be sometimes on any large project, then it's the responsibility of the guys further up the tree to fix those problems rather than the job of the bottom-tier code monkeys to deviate from their specs.
Don't get me wrong, if you've got a good team building your company's software then I'm all for shallow management hierarchies and empowering individuals. But we're talking about a national government running a massive project to automate a large chunk of its tax and benefit system, with who knows how many people and of what quality involved in building it, and with literally life-changing consequences for many, many people if it goes wrong even for a few weeks. The rules of the game are very different, and the management style has to allow for that.
Small companies like Facebook?
You're citing a company whose motto is "Move fast and break things", a company that is indeed infamous for breaking its software all over the place and introducing changes its users don't want, as evidence that cowboy programming works at scale?
Facebook have been shrewd about their marketing, and they've developed probably the most effective lock-in/network effect strategy in software history, and they've also been lucky at a few times when it counted, and they're successful as a result. Please don't confuse any of that with technical merit, which really has very little to do with their success or failure at this point.