![](https://midwest.social/pictrs/image/373fb50c-30fe-45a4-97f1-ae383a737824.jpeg)
![](https://beehaw.org/pictrs/image/f83a7ff8-4e85-47a3-b4df-6a814e29c5d4.png)
Yes.
In fact I used to help them out before knowing how horribly racist and sexist and selfish they are.
Yes.
In fact I used to help them out before knowing how horribly racist and sexist and selfish they are.
My neighbors vote against doing anything positive like holding companies resposible and making them change their practices to fight climate change.
Fuck 'em.
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.
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.
People think it AI intelligence is comparable to how a hovercraft hovers, as in the word is taken literally, but it is actually comparable to a Hoverboard.
Stalin said he was joking, but probably wasn’t.
Understanding things leads to new possibilities.
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…
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.
Requirements ≠ Documentation.
They are part of documentation, but not all documentation.
To keep the number of characters in the core cast to a reasonable size.