Thank you for the response with the exact level of pedanticness I would have gone for personally. You saved me some time.

This is just he exception that proves the rule.

It's when you find TWO exceptions, that you should start to worry about the rule itself...

How does Apple "monetize" its userbase information right now?

It doesn't, because it doesn't need to (see: Stock Price, cash on hand).

Why does Apple feel the compulsion to plow money into an inferior map service?

Apple maps are superior to Google Maps at this point. They are more readable for one thing (true from the outset) but also I have noticed more errors lately in Google Maps than Apple Maps (and Google Maps always had errors to begin with).

The reason Apple continues forward is because that way they do not have to worry about how users are monetized by other map providers... which you are if you use Google Maps.

Originally said:
Stock valuations are based not only on actual assets, but future growth and earnings potential.

You replied:

They're comparing the stock valuation to what the company would sell for if purchased. When you sell a company, you're also selling the "good will" and other value inertia things like brand familiarity

Goodwill is ALSO something that can increase in the future, just like monetary assets - you buy stock with the idea that the entire company value (including goodwill) will grow. So the original point is still a sound one.

Clinton did not selectively keep emails she thought were state-department related - she came up with a small list of keywords she thought would match state-departmnent matters and deleted ANYTHING THAT DID NOT MATCH.

So basically her keeping state department related emails is only as true as her ability to come up with keywords that matched everything she did over years of service...

Not to worry though, the Chinese and many other foreign governments have a full backup, which they have pinky-sweared not to use as leverage should Clinton be elected president.

I totally agree that ad-blockers are immoral. Realistically how can you support denying a web site ad revenue which is the only reason it can continue to exist?

However, just as immoral are the way ads are tending to be presented now. Full screen ads as noted, or un-avoidable popovers are to my mind a betrayal from the other direction - a web site needs revenue to survive, but that should not come at the expense of the sanity of the reader.

My solution is to simply sop using a site if I find the ads grow too obnoxious. But I also really can't see anything morally wrong with blocking ads from a web site that has gone too far in embracing abusive ads, almost as a form of punishment...

James, did you take your stepfather's car again? You'll wreck that thing some day. It's over 250 years old, so it's a real classic, and he'll be pretty upset if you ruin it.

At one point we needed the government just to reach space.

That time has passed. What we need now is not one gatekeeper to bring us into space, but the gates to be flung open. NASA still has uses but the majority of space travel and research going forward should be done by the people outside the government, the people who from time immemorial have been always able to do something hard and dangerous and expensive and make it better and faster a cheaper and more accessible to everyone.

Do you want to visit space? I do. I know that would never happen just having NASA around, just as I know it will be feasible giving some of NASA's money to SpaceX and its ilk to refine and commoditize space travel.

Sounds like a typical offshoring disaster. I hope somebody somewhere up the command chain felt the consequences.

I've also had luck with waterfall-like development models, on projects from six months to about four years (although the four-year project did have three distinct iterations in order to manage risk). That was for a vehicle-mounted sensor to detect land mines, so there were obvious reliability concerns -- and we could meet them because waterfall let us budget time for detailed failure mode analyses, rather than trying to make that fulfill some user story within a single sprint.

Of course you would say that. You would still be wrong. What you call "organizational dysfunctions" -- but everyone else would call "a normal mix of people" -- can be handled more effectively under a waterfall-like process than under an Agile one. That doesn't make it less efficient.

If you want the same kinds and amount of work product (including detailed requirements, design documents, formal verification, etc.), Agile is likely to be less efficient because you start lots of developers writing code before anyone has a good grip on what the project should look like -- and they continue working furiously until the end. It looks nice because you have something to show and everybody is busy, but the something doesn't fit the need and you're burning through your budget.

Telling people what is blocking your progress *is* pointing fingers, friend.

Waterfall does not need that many long meetings. Instead of five 15-minute scrums in a week, I've typically had one 30- to 40-minute status meeting in a week.

Waterfall does not require the users to know in advance exactly what they want. Why do agilistas spout that nonsense (beyond it being part of the creed)?

If your project leads -- managers, systems engineers, whoever deals with the customer most -- do not know how to deal with vague requirements, irrational schedules, or requirements changes, your project is going to fail regardless of methodology. Agile exacerbates and encourages those problems.

Successful waterfall does not have the problem you claim with requirements elicitation because that is part of what a good system engineer does. I guess agilistas have never worked with good systems engineers. Unless the customer is a professional software developer, it is natural that he or she can't explain their business requirements in the kind of detail that is needed to guide software development and testing. The development team can still develop "use cases" (IMO a more cumbersome, but clearer, term than "stories" -- but basically the same thing) and refine them enough for developers to use.

Waterfall is fragile to change only to the extent that the project is mismanaged -- yet when agile is mismanaged, it fails more spectacularly than waterfall. Agile is designed to make a more convincing appearance of progress, but it is also designed to throw more code away.

Put as much lipstick on that pig as you want, but it's still going to squeal.

A functional waterfall-style team needs two people to be good at their jobs: A manager (to keep everyone pointed in the same direction) and a system engineer (to make sure that direction is a good one). By your argument, a functional agile-style team needs almost everyone to be good. Most teams aren't like that, and the ones that are will do pretty well with any methodology.

Where did you go during that six months, and did the team's manager get fired for not doing his or her job?

If developers are not allowed to add their own bugs or issues, then either your team is too big for agile or the project is too small for your team. Instead of prohibiting that, somebody needs to oversee all the bugs and issues that get added, and part of their job should be to provide feedback when anybody submits an issue report that is not well-aligned with the customer's or user's interests.

How do you square that advice with the agile advocacy of incremental development starting with a minimal prototype? Anybody who thinks about it objectively realizes that you don't want a mock-up to be backed by anything like your final code, but Agile strongly calls for developing a minimal app that can finish user stories -- and then solving more stories by extending that code. That conflicts with the first pass being a mock-up that you expect to extensively rework.