To avoid the Agile crowds inevitable "but, again, that's not agile" (even though that's the agile that exists out in the world) - just change the scenario to:

Customer: I want a house at this location...

Development team designs and builds a house.

Every two weeks development checks with customer, customer is happy!

24 Weeks Later

Customer: Hey everybody, here's our new house.
Another Department at the Customer: We need a house we can drive to the lake.

That's the stuff that happens constantly.

You can follow Agile perfectly and yet customer satisfaction is vastly more complicated when you let them design your software. They don't know to tell you that you can't encrypt certain things because it breaks the workflows of tools they didn't even know their company uses? Or that you can't change the formatting of something because it breaks another tool. That you can't augment the data in their system because it now violates GDPR because they don't know wtf GDPR is? Et cetera, ad nausem...

Let's create a fictional company by which we can answer your questions.

CoolSoft has a vision to create a revolutionary product that crushes the 3D content creation pipeline market (think 3DSMAX/MAYA market.) They're going to call this product Cool3D (ugh...) and their primary target are AAA game development teams.

DUMP - Christ almighty, yes, dump this hideously inappropriate idea. Instead, find world class technical directors that have been living/breathing/eating 3D content pipelines for at least 10 years and who want to create something great - in other words pay for DOMAIN EXPERTISE so you can build the bedrock of your product by relying on their expertise augmented by your own and your teams' synergies.

NOT AGILE - Classic Agile zealot straw man - as if coming to market as soon as you think you will benefit is something new, LULZ. Of course you build to MVP, people have been doing that for 40 years - this is not an 'agile' thing, only the ubiquity of the term MVP is. It's not a question of keep, it's something you always do, whatever your methodology is (never heard of one that said to over develop for your market...)

DUMP - Late significant changes should require a drastic evaluation of how you came to your, and require a change control process that includes identifying why your highly paid team of domain experts totally messed up. It's possible the reason is legitimate, and if the opportunity cost balances out the loss of market - go ahead and make the changes. PMs shouldn't count on getting bonuses though.

DUMP - Cool3D only hires PMs who were designers and/or implementors of AAA art content pipelines for 10 years or more. Nobody knows more than they do, that's why you hired them. They can, of course, make mistakes - but it's incredibly unlikely they'll make mistakes that damage your software in the marketplace.

DUMP - Cool3D thinks this is criminally stupid. It's going to take them 12 months minimum to get to better, and that's not counting the suite of tools necessary for multi-platform integration and their SDKs (ios/android/ps4/xbox/pc.)

DUMP - You clearly have only worked with limited types of software and software companies (maybe not even software companies) because you seem to be unable to imagine scenarios that totally invalidate that type of thinking...

DUMP - Holy f*** no - this is the single biggest problem with Agile - and it's almost always wanna-be bullshit PMs (who are really poorly trained project managers) who love to use this crap - because they then have ZERO RESPONSIBILITY for the result. They don't need to know shit, just ask the customer. Cool3D would never even dream about building their software this way - that type of stuff happens in beta.

Product Managers don't do vision, they're the people who are supposed to translate the company's vision into a market strategy - in other words "okay, we understand the vision, but how do we get there?" This means they either work from an MRD or create one (if domain experts) and then generate a PRD - no software company, even "Agile" ones should be without a PRD (or what would technically be the equivalent.) The PM doesn't disappear, they're there every day answering questions, revalidating their PRD, coordinating between teams in order to produce an aggregated result, working with the Dev Manager or Dev Lead (depending upon your team setup) to manage priorities (which means you can work via sprints or Kanban if you wish, but that's internal - depends on the visibility you want to monitoring the process.) Why would a PM go disappear for a year, even in some crazy waterfall black hole?

NOT AGILE - Again, another bullshit Agile zealot straw man. Oh, before Agile, nobody built projects around motivated people. Nobody gave developers an environment of support. Nobody trusted people. Oh, wait, if Agile trusts people to get the job done, why don't the developers manage the backlogs and why are there reviews? LOL.

DUMP - Another bullshit strawman. Why is having a PRD and a face to face every day mutually f***ing exclusive? The whole point to writing shit down is so that if your PM quits, is fired, gets hit by a bus, takes vacation, or can't keep track of every decision that results in Cool3D having a 3 million LOC codebase - you've got a reference. Oh, and if you ever hire another QA, dev, PM, or marketing person - guess what? They can get up to speed by reading the PRD and know what the f*** is going on without spending 3 days with the PM.

Like any religious movement, some Agile people love to create ridiculous black/white situations that (a) aren't black or white and (b)aren't mutually exclusive.

NOT AGILE - again, there's no reason to have software that doesn't work until you're ready to release, it should be testable ASAP. Oh, wait, as an Agile guy you would rather use the market as QA, right...

WTF? This is true, but it's also true of methodologies other than "Agile" - shocker - if you do it correctly, just like Agile needs to be done correctly.

Damn, you haven't done much Agile with a real live customer if you haven't been on an Agile death march, LOL! Every methodology I've ever seen is equally subject to this problem, but usually driven by different reasons. E.g., for a spiral project it tends to be time to market compression, or another market driven factor such as a competitive first mover leading to changes. For Agile, in a project appropriately using Agile, it's a commonly customer who doesn't know what they want (and oh, those are so rare, right?)

NOT AGILE - Wait, before Agile existed people didn't pay attention to technical excellence continually? LOL.
"Good design enhances agility"? Sorry, Good design has got absolutely f*** all with agility - unless one of your design goals IS agility.
At Cool3D that wouldn't be necessary because you have the absolute best customers in your PMs themselves - which is why you pay them so much.

NOT AGILE - Common to anything, ...duh...?

DUMP - Yeah, best architectures and requirements and designs emerge from self organizing teams? Not at Cool3D, they're not going to led some 5 year C++ dev tell the woman who built RockStar San Diego's art pipeline that he thinks his ideas are better than hers, lol. Oh, and the 3 yr Python 'veteran' wants his P2P node based network architecture to be used instead of the Cool3D Chief Architect's scalable/reliable multi-region/multi-provider architecture... Yeah, good idea. Hey, maybe these 'Agile' guys could "trust" the PMs and the architects to do their jobs... I seem to remember you suggesting that.

Wait - Agile invented the post-mortem? The dev cycle review? Feedback meetings? Progress reviews? Holy sh**, how did we do all that before Agile came around and told us it had value?

Look, as I mentioned previously, for the right job - Agile is 100% the best approach - but it's a TOOL IN A TOOLBOX. Right tool for the right job. It's agonizing watching large companies, who aren't software companies, misapply Agile and f*** it all up - primary because (here I go again) of "Agile PMs" - In other words Product Managers with zero domain expertise in a job where their primary value is their domain expertise...

...its pervasiveness.

It's a valuable tool IN A TOOLBOX.

If you're NOT an ISV, and you make software solutions for individual customers (which is what the vast majority of software developers find themselves doing) - then Agile is probably the right way for your company to go.

If you ARE an ISV (and Independent Software Vendor makes products, unlike the folks above who work on PROJECTS) then use Agile at your peril.

ISVs that use agile are those that tend to have "Product Managers" who are not actually Product Managers, but are instead "Project Managers" with a penchant for making products up out of virtually thin air ("Oh, a customer wants this, so this must be part of the 'product.')

ISVs that know what they are doing start with Product Managers - because a Product Manager has DOMAIN EXPERTISE that means they actually know what the market wants - not just a single customer. The problem for wanna-be ISVs is that real Product Managers are expensive and difficult to find (but they're out there) due to the Product Management market being swamped with Project Managers calling themselves Product Managers.

If your company has a technology or product related vision - you should not use Agile.
If your company has a market dominance or growth related vision, and you make software tailored to a specific customer's needs - you should probably use Agile.

...and post them all over FaceBook now that they're "free speech"

BTW, it takes a little over 200 million years to completely rotate around the center of our galaxy (i.e. a 'cosmic year')

You seem to be forgetting that the neutrino has been traveling to us for, apparently, 4 billion years. The speed at which galaxies move over 4 billion years is significant - not to mention the rotation of our galaxy relative to the orientation of the speculated galaxy is huge.

How could they possible track where the neutrino came from given their incredibly sporadic observability for measurement, a spinning earth, a spinning solar system, a spinning arm of the milky way - and 4 billion light years distance?

The article says they notified astronomers of a patch of sky that was a candidate for the source - how could this be correct if our galaxy is spinning?

Again, apologies if this is a dumb question, but thank to Einstein I think everything's relative - especially the orientation of bodies ;).

If you're not going to be hybrid (which gives you other opportunities) then you simply DNS load balance between regions AND cloud providers. Easiest way? Containerize.

The complexity comes into play around your databases, but there are a myriad of well known solutions to all of these problems.

There's no other rational way to provide solid service that to spread your risk.

Setup DNS Failover (or load balance if you prefer)
Setup in multiple AWS regions.
Setup in multiple GCE regions.
Optionally setup for Azure
If you're really paranoid, have an on premise instance somewhere local to you (or a metapod in house or something similar.)

Containerization makes all of this vastly simpler than in the past.

As many others have mentioned - don't trust anyone to be up all the time, trust that at least one of them will be up all the time.

Ridiculous. While non Republicans (Dems, Libertarians, whatever) are made up of fallible human beings just like Republicans - this story is interesting BECAUSE it's a Democrat acting like a Republican. The majority of Dems are for Net Neutrality in some shape or form that most people would recognize as 'neutrality', the majority of Republicans are against those forms of Net Neutrality.

It's like saying that because there are (something like 4 or 5) pro-choice Republicans that "Republicans are just as beholden to the pro-choice mafia as Democrats."
(I'm pro-choice myself by the way, and independent.)

Isn't its methodologies - it's the fundamental premise that it's a solution for everyone and every thing.

If you're building custom solutions for anyone (consumer, SMB, Enterprise) - Agile is likely your friend. Go with Agile.

If you're building a consumer facing web application - Agile is possibly your friend, it depends on how clear a vision you have. If you're not sure - go with Agile.

If you're building a PRODUCT (something you expect to use unchanged - excepting, of course, new additions and features) for the Enterprise - Agile is NOT your friend - but it is most certainly the friend of the integration team who will be deploying your PRODUCT into that enterprise.

Agile is hugely beneficial in the right scenarios - usually a scenario where the people who want something don't know what it is they actually want - they just know they need something fixed.

Agile is hugely detrimental in the wrong scenarios - for example when you have a company that hires 'Agile Product Managers' who are NOT domain experts; ergo, they have no idea what is or is not good for the target market verticals.

The other problem with Agile is that they created (somewhat accidentally) a strawman argument to establish themselves - that if it's not agile it's some kind of horrifying version of 'waterfall.' In other words, a black and white situation that's simply bullshit.

I've run teams where Agile was the only reasonable approach - and it worked well for us. I've run teams where Agile would have been a disaster for us and a waterfall/spiral type of approach worked well for us.

Tools in a toolbox people - just like operating systems, languages, patterns, testing methodologies - et cetera. Right tool, in the right place, at the right time.

Know them all (or as many as you can) - know their strengths and (sometimes more importantly) their weaknesses.

The really interesting time is when you build a startup and as the company matures, so does everything inside of it (technology, operations, organizations, processes, et cetera.) You may spend 90 days head down and very NOT agile, and then at seed round embrace Agile because it's right for you. You may be agile for a year or two until you close an enterprise deal - and then perhaps you re-evaluate using Agile - or modify it.

The point is (that I am very poorly making) - You need to know when Agile, and/or some particular aspect of Agile, is or is not appropriate for you and either embrace it or distance it. Don't fall for marketing hype, or the legions of people who cover their incompetencies (primarily in the world of Product Management) by hiding behind it.

...you trained a multi-layer perceptron on gruesome images, then submitted 'impossible' to classify images to it and it matched up against the only other things it's seen before?

Wow, who could have guessed that would be the outcome...?