It explains what it does, it does not confirm that it is what was intended.

The user is always right about what they are willing to spend money on. That doesn’t mean they know what they want, although a lot of people don’t want to change.

That doesn’t mean all change is good, and it isn’t like any UI will ever meet everyone’s preferences. For example, I hate adaptive design interfaces that are significantly different in confusing ways on different resolutions. Like I understand switching a static menu to an expandable menu, but not moving the relative location of certain buttons from the bottom of the screen to the top or vise versa. But that might make sense for some use case that isn’t how I interact with it.

To keep the number of characters in the core cast to a reasonable size.

Also the time spent getting ready for office appearances and prepping lunches (or the cost of buying lunches away from home).

Is anything other than sexting referred to as inappropriate when a minor is involved?

Pretty busy at the moment, I’ll get back to this later when I have sone free time.

Huh, my first thought was that they went to the farm upstate where everyone’s pets end up.

Note they left the “…and improved” off the (New) title.

Clicked “Continue without disabling”?

Yes, yes I have.

Like the startups that ‘disrupt’ the established system by ignoring laws and breaking the parts that worked and selling it like an improvement.

‘Ride sharing’ (unregulated cabs) was only cheaper because of investor funding allowing them to undercut on pricing, abusing the concept of contract workers, and the companies ignoring laws. That isn’t ‘disruptive’ by being innovative, that is cheating the system.

Like all sayings, there is context for moving fast and breaking things.

The saying means that when creating something new for profit, don’t worry too much about trying to figure out all the details beforehand and figure it out as you go. This will inevitably cause things to break, but being able to quickly fix that when it happens is the same skills needed to create new features as you go.

The saying does not work with large and complex established systems where breaking things wreak havoc.

Then some hackers get in and reprogram the AI CEOs to value long term profit and employee training and productivity. The company grows and is massively profitable until some venture capitalists swoop in and kill the company to feed from the carcass.

Tech CEOs or AI?

Just kidding, I know it is both.

Less time is spent handling on-call issues if you do the code reviews, documentation, and testing…

Aged like a fine wine!

I’ve used a wrench to hanmer in a nail more than once, but that doesn’t mean it was the best tool for the job.

It isn’t that agile can’t be used for something big, but that the design will likelyntun into hard requirements that must be approached certain ways and at thst point you are using agile to do waterfall. If it improves communication earlier in the process (which waterfall does not prohibit) that is great!

If you write it down it is documentation. When requirements are written down, they are documented! Requirements are not the same thing as specifications either, but both are documentation!

You are saying that only technical documentation counts as documentation.

A large and complex system with an API and interacts with multiple other systems that is maintained over multiple years will be killed by agile through scope creep and inconsistent implementation when there is staff turnover. People will get great ideas that break other things snd without a cohesive vision across the team, things will be missed and unfinished because people focus on their part and not the whole.

You can add the structure to keep things coherent and spend more time doing documetation up front so people can review the API and do it right the first time instead of redoing it multiple times.

Agile is great for some projects, but ataff turnover, coordination, and meeting any kind of complex external requiirements means it isn’t a great fit for all projects.

Being able to adapt does not require all of the other parts of agile.

So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.

The details on HOW to authenticate are ALSO documentation. Not all documentation describes functionality.