Yes, victory is the end goal. But sometimes your opponent is playing a game one or 2 levels more nuanced than you realize. For example, stealing is an easy way to get what you want. But in the long run, it's a losing game. Take it one level up, and you've got people who work for a living instead, and are able to stay out of jail. Take it up another level, and you've got the folks who basically cheat at business without getting caught. Another level up, you've got the people who out-maneuver the cheaters. Take it up another level....

I'm a big proponent of Agile (mostly XP, mostly anti-Scrum) and have contributed some to the #noestimates "movement".

I don't really mean that nobody should ever estimate anything. I mean that I've never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I've seen frequently:

1. We're not good at estimating how long things will take. We're usually optimistic about how quickly we can get things done, and almost always miss thinking about things that will take more time. I've never seen a case where a project is completed more quickly than estimated. I've only rarely seen fine-grained (story-level) tasks completed more quickly than estimated.
2. Management asks for estimates and then treats them as deadlines. The team then learns to inflate their estimates. Then management learns to reduce the estimates they're given. Given fudge factors in each direction, the estimate no longer has much reliability. Even if you're using story points, the point inflation/deflation leads to less consistency and therefore reduced reliability.
3. Estimates that are given are negotiated down, or simply reduced. This leads to the question why you'd ask for an estimate and not take the answer provided. If you're not going to listen to the answer, why are you asking the question? This is probably the craziest one on the list -- given my first point, increasing an estimate would make sense. Reducing the estimates is just magical wishful thinking.
4. Plans change and work is added, but the deadline (presumably based on the estimates) is not changed to correspond with the extra work involved. So again, you're not actually even using the estimates that were given.
5. Management dictates deadlines arbitrarily, without speaking to the people who will be doing the work. Spending time estimating how long each task will take when the deadline is already set is completely pointless.
6. Almost every deadline is complete bullshit, based on nothing. Often the excuse is that marketing needs to know when something will come out, so that they can let people know about it. Why they need to know the exact release date way in advance, I've never been able to figure out. Many people intuitively know that the deadlines are bullshit, and will likely be allowed to slip. The only exception to bullshit deadlines I've come across are regulatory deadlines.
7. Estimation at a fine-grained level isn't necessary. Many Agile teams estimate using story points, and determine a conversion from story points to time based on previous empirical data. This is fine, except that the time spent estimating the story is wasted time -- counting the number of stories almost always gives the same predictive power. Teams tend to get better at breaking up stories over time, so that they're more consistent in size, so this becomes more likely over time.
8. The ultimate purpose of an estimate is to evaluate whether the proposed work will be profitable, and therefore worth doing. Or to compare the ROI (return on investment) between alternative projects. But to know that, you'll have to know what value that work will provide. I don't believe I've ever seen that done -- at least not at a fine-grained level. Usually by the time you're asked to estimate, the project has already gotten approval to proceed.

I'll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren't really even taken into account very much.

My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you're pretty certain of the expected value, I'd probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there's uncertainty in the expected value, much more.

Another way to mitigate the risk of throwing money at something that's not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value. (Realistically, you'll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first -- get that out into production as soon as possible. Once that's done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.

At a fine-grained level, if you're using story points, I'd ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I'd still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size -- with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you're looking for?)

And don't forget Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

It's called Rubber Ducking. The idea is that by talking out loud, you have to form your thoughts into words, which requires you to organize your thoughts more completely. Think about all the times that you've gone to ask someone a question, and as soon as you ask them the question, you figure out the answer yourself. Whether you use a rubber duck, a live video audience, or another person doesn't matter much. This is one of the reasons that pair programming can be quite effective.

Cars also help terrorists. Maybe we should consider restrictions on them too, to make sure they can't be used for terrorism. And guns help terrorists. I certainly don't see the Americans raising a fuss about that. Curiously, the UK doesn't seem to be raising a fuss about that either. Heck, western governments frequently help terrorists. Perhaps we should address that one first.

How bad are your company's lawyers, that they can't simply show on a 4' x 6' poster the contract terms "not liable for bugs, even if known" and win a lawsuit about a bug?

Oh, I'm sorry. I'm sure he was just following him to give him a candy bar.

If you believe that courts only hear cases for guilty people, or only convict guilty people, then our conversation was over before it started.

And it's not designed to protect you from improper conviction (because that would be impossible). It's designed to protect you from additional punishment for pleading your innocence.

You should probably watch Dont Talk to the Police (or any of several similar videos and articles). It explains how an innocent person can try defend himself and still get into trouble.

Have them agree to be bombed if they are found to have any remaining chemical weapons after the turn-over.

Because if I'm a witness, telling the truth doesn't lead to me being punished. (If my testimony could lead to my prosecution, then I would be able to invoke the 5th Amendment right to not testify, unless I had been given immunity.)

So a witness doesn't have the "damned if you do, damned if you don't" dilemma. The Wikipedia article (and many others covering the reasons for the 5th Amendment protections) does a pretty good job of explaining this.

I think you could make an argument that prosecutors are doing something similar in recent times. They pile on lots of charges, hoping some will stick. (And hoping that juries will see all the charges, and make an assumption that at least some of those must be true.) The time and cost of defending against all those charges is so daunting that the suspect is faced with 2 bad choices -- spending several years of their lives and all their savings defending themselves, or pleading to a lesser charge even though they did nothing really wrong. This dilemma is basically the same dilemma that the 5th Amendment is trying to protect us from.

If only there were historical documents about the context in which the US Constitution and Amendments were created. Or encyclopedic collections of knowledge, providing references to such historical context.

Copyright before 1976 did NOT automatically get granted when the ideas hit a fixed form.

What kind of crack are you smoking? 1. He followed Trayvon -- he was the one doing the assaulting. 2. Do you truly believe that the American justice system treats blacks better than whites?

If the NSA can monitor anyone (which Snowden claims, and which appears to be true) then there's likely some monitoring of Congress going on. Sad that Congress itself doesn't seem to realize this. (Or at least not those either profiting in some way from the NSA or being blackmailed by the NSA.)

I'd point out that the US Constitution (article 1, section 9) forbids ex post facto laws -- but it's pretty clear that the Constitution is not really being followed in this case.